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Figure 1 
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Figure 2 

200 Typical General Purpose Computer/ 



t a 


tt Mt — 




■titmt 


■ 
■ 


i MI 1 




uStS. i 


«1I 





KEYBOARD 



OTHER 
UNITS 



DISPLAY 



' 3 



201, 



205^ 



20^ 



1/ 


0 


CPU 


MEM 


ORY 



211 



FLASH 
MEMORY 
CARD 



OTHER 
UNITS 



CD-ROM J17 
DRIVE 




02/02/2004, EAST Version: 1.4.1 



U.S. Patent Nov. 4, 2003 Sheet 3 of 17 US 6,643,652 B2 




02/02/2004, EAST Version: 1.4.1 



U.S. Patent 



Nov. 4, 2003 



Sheet 4 of 17 



US 6,643,652 B2 




02/02/2004, EAST Version: 1.4.1 



U.S. Patent Nov. 4, 2003 Sheet 5 of 17 US 6,643,652 B2 




02/02/2004, EAST Version: 1.4.1 



U.S. Patent Nov. 4, 2003 Sheet 6 of 17 US 6,643,652 B2 




FIG. 6 
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METHOD AND APPARATUS FOR required to allow distributed objects to communicate with 

MANAGING DATA EXCHANGE AMONG each other across either the client-server or server-server 

SYSTEMS IN A NETWORK boundary has been provided by the EnterpriseJavaBeans 

(EJB)™ component architecture. This new architectural 

This application claims the benefit of U.S. Provisional 5 system and related tools and systems are well documented 

Application No. 60/176,137, filed Jan. 14, 2000. This appli- and well known to those skilled in these arts, 

cation is also related to the following utility applications Attempts continue to be made to employ these new 

which are filed on the same day as this application: systems and architectures in the process of building generic 

Ser. No. 09/760,068, filed Jan. 12, 2001, entitled "Method applications systems platforms, in an attempt to make the 

And Apparatus For A Business Applications Manage- 10 applications platform independent of a given hardware and 

ment System Platform;" software platform, and to make them easier to use by 

Ser. No. 09/759,491, filed Jan. 12, 2001, entitled "Method developers and end-users. For example, U.S. PaL No. 6,125, 

and Apparatus for a Business Server;" 363 on Se P- 26 > 2000 10 Eu & ene Buzzeo et al Provides 

Ser. No. 09/759,856, filed Jan. 12, 2001, entitled "Method 15 an multi-toaded application development 

, . ^ ' , , * _ ' „ is system and method for developing resource information 

and Apparatus for a Web Content Platform; software, wherein a three tier framework (web client and 

Ser. No. 09/760,432, filed Jan. 12, 2001, entitled "Method we b browser— web server— application server) is disclosed. 

and Apparatus for an Information Server;" ■ The "system disclosed uses JAVA objects" "as connectors', 

Ser. No. 09/759,062, filed Jan. 12, 2001, entitled "A components, agents, event servers, common objects with 

Method and Apparatus for an Improved Security Sys- 20 which to build applications for database related applications 

tem Mechanism in a Business Applications Manage- which are hardware platform independent Tht system 

ment System Platform." described in this Patent tries to solve the problems of 

distributed object communications through the use of the 
COPYRIGHT NOTICE Common Object Request Broker Architecture (CORBA) 
A portion of this patent document contains material which 25 ai *d the InternetlnterORB Protocol (IIOP). Such platform 
is subject to copyright protection. The copyright owner has independent languages, tools and sub-systems, while osten- 
no objection to the facsimile reproduction by anyone of the sibl y making it easy for applications developers to create 
patent document or the patent disclosure, as it appears in the new business applications, nevertheless present an over- 
Patent and Trademark Office patent file or records, but whelming technical problem for a user with a need for an 
otherwise reserves all copyright rights whatsoever. 30 efficient, integrated business system. A system using one 

framework is unable to transfer data to a different 

TECHNICAL FIELD framework, as systems implementing one framework will 

The present invention relates to the general field of h u ave a * fferent «PP«i««« programming interface API than 

computers, telecommunications, and computer and Internet 3J £ e a PP" cabon Programming interface API of another sys- 
related systems. More specifically the invention relates to 

systems and processes to be used in a business systems . Accordingly, there is a need m the art for a modular 

platform generally used to integrate disparate business appli- interconnect system containing data import, export and 

cations systems in an efficient manner, across multiple event monitoring and reporting facilities which are protocol 

hardware platforms, independent of related applications. There is a need for an 

40 interconnect system which implements a generic connector 

BACKGROUND framework with pluggable system specific components uti- 

_ . , , . . , . , lizing native application programming interfaces of systems 

The Internet and other communications networks provide to raa rt ^ { rt of data from extcrnal systemSi 

a mechanism for communication and transfer of data is also a need for such an interconnect system utihzing 
between a wide variety of systems and platforms. There is a 45 XML, and there is a need for reliable monitoring mecha- 
need for a system for managing the exchange of data and nisms fof cfa tQ data [n ej£ternal ^ ^ 
information among applications which may be housed on ^ ^ and otDefS m y&6ous Qew 
disparate hardware platforms and in diverse locations. and novel ways as more fully described below. 
Moreover, there is a need for a system that provides stan- 
dardized access to connectivity with other systems and 50 SUMMARY OF THE INVENTION 
platforms in a users network. The present invention presents a method for managing 
Prior art systems of this type typically have an infrastruc- data exchange among systems connected via a network. A 
hire which is tightly coupled to application products, spe- plurality of predefined stylesheets are generated, with each 
cific hardware platforms and specific Operating systems and stylesheet describing a mapping between a system specific 
related services. Such systems are difficult to maintain, 55 local format and a generic interchange format. A data object 
difficult to upgrade and difficult to extend to other applica- is received from a first system in a first system specific local 
tions as well as usually requiring redundant data input for format. This data object is translated from the first system 
their specific applications. In the past, developers have specific local format to a generic interchange format object 
turned to object-oriented programming (OOP) to improve with the predefined stylesheets using a system specific 
programming and code maintenance efficiency for such 60 service component which utilizes a native application pro- 
systems and to the use of hardware platform independent gramming interface of said first system. The data object is 
languages like Sun Microsystems™ JAVA™ language and then translated from the generic interchange format to a 
system, as tools for developing such platform independent second system specific local format object with the pre- 
applications support systems. Until recently, the use of Java defined stylesheets using a system specific service compo- 
has been focused on the client side of the client-server 65 nent which utilizes a native application programming inter- 
system architecture with the development of JavaBeans™ face of said second system. The translated data object is then 
and Java servelet generation. More recently, the technology transferred to the second system. 
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Id one embodiment of the invention, the step of receiving FIG. 5 illustrates an alternative configuration of the sys- 

a data object from a first system in a first system specific tern which contains the invention. 

local format includes receiving a request to export a data fjq 6 ^ aD alternative depiction of the platform of the 

object from a first system, identifying a local data object preS ent invention. 

identifier utilizing a mapper component, identifying a docu- < m .„ , t . _ . 

ment type utilizing a mapper component, idendfying a nG - 7 illustrates a more detailed configuration of an 

stylesheet and transformer using said document type, and exemplary business server portion of the current invention, 

extracting the data object from the first system. FIG. 8A illustrates a more detailed configuration of an 

The present invention presents a system for managing exemplary Web Content Server portion of the current inven- 

data exchange among a plurality of systems connected via a 1Q tion. 

network. The system comprises a network interface, FIG. 8B shows a process flow diagram illustrating how to 

memory storing data and programs of instructions, and a produce dynamic web content. 

processor coupled to the memory which executes the pro- RG 8C shows a process flow diagram illustrating the 

grams of instrucitons and accesses the stored data. The page development process. 

programs of instructions comprise a first component for 1C „ .« . 4 c a u j- * c ^ i . 

translating a data object from a first system specific local " nG - 9 n lU ^ a,eS 8 prefcrred embodunenl of the ,n,er - 

c 4 4 * c * l* 4 -i connect Backbone, 
format to a generic interchange format object, a second 

component for translating the data object from the generic ^G. 10 .shows .a process flow .diagram .illustrating a., 

interchange format to a second system specific local format purchase order delivered from a Source site to a target 

object, and a third component for transferring the data object 2Q system through Interconnect. 

between the first and second system. The first component FIG. 11 illustrates one embodiment of the structural 

further comprises a system independent service subcompo- overview of an IDK. 

nent and a system specific service subcomponent utilizing a 12 illustrates one embodiment of a functional over- 
native API of said first system to translate said data object to vicw of ^ information Distributor. 

4 J CD K ri ? £ terchan £! f0nnat ^TtiT* ' ? redefined 25 FIG. 13 illustrates an exemplary view of APIs associated 

stylesheet. The second component further comprises a sys- ^ ^ Information ^ ribu [ or . 

tern mdependent service subcomponent and a system spe- 
cific service subcomponent utilizing a native API of said first F 10 ; illustrates an exemplary view of using Informa- 
system to translate said data object from a generic inter- t * on Distributor or IDK. 

change format object to a second system specific local ^ FIG. 15 illustrates an exemplary overview of Query 

format object using a predefined stylesheet. Objects. 

The system may also include a monitor component for FIG. 16 illustrates an exemplary overview of the Imple- 

monitoring changes of a data object at a system, with the merit Custom Delivery Service. 

monitoring component having both a system independent p, G 1? muslt&tes a preferred embodiment of the Busi- 

service subcomponent and a system specific service com- 3S aess ^^vs Management System Platform. 

ponent utilizing a native API of the monitored system to 

monitor changes of the data object. The system may also DETAILED DESCRIPTION 
include a mapper component for identifying a local object 

identifier and a document type. The present invention provides a solution to the needs 

Still other embodiments of the present invention will 40 described above through a system and method for integrat- 

become apparent to those skilled in the art from the follow- nig the disparate applications, and managing the applica- 

ing detailed description, wherein is shown and described tions processes in a hardware resource and user effort 

only the embodiments of the invention by way of illustration efficient manner. The automated system of the present 

of the best modes contemplated for carrying out the inven- invention uses a business systems platform architecture 

tion. As will be realized, the invention is capable of modi- 45 comprised of several unique servers in a base platform (the 

fixation in various obvious aspects, all without departing "Platform") to efficiently manage multiple applications 

from the spirit and scope of the present invention. which may themselves generally be distributed across a 

Accordingly, the drawings and detailed description are to be network. The platform makes use of a collection of Core 

regarded as illustrative in nature and not restrictive. Services which provide additional security, internationaliza- 

nFSPRlPTlON OF THF DRAWINGS SO tion services, and reporting services which are applicable to 

DESCRIPTION OF THE DRAWINGS flU applications nc Corc Services are made available to a 

The features and advantages of the system and method of multitude of common business objects, which themselves 

the present invention will be apparent from the following are made available to various applications, 

description in which: The present invention is a Business Applications Man- 

FIG. 1 illustrates a typical configuration of Internet con- 5S agement System piatform Architecture (the "Platform" or 

nected systems representative of the preferred embodiment alternatively the "SABA architecture") which is designed to 

of the present invention. maintain and use a set of unique servers and common objects 

FIG. 2 illustrates a typical general purpose computer to generate the set of tasks required to be performed to 

system of the type representative of the preferred embodi- complete a designated business transaction in a concrete, 

ment - 60 and useful way. In the preferred embodiment, the platform 

FIG. 3 illustrates the general three tier relationship permits application developers to work on the business 
between user, web-servers and their related applications- aspects of the application without having to focus on trans- 
server, and the database management system. action management, security, persistence of data or life cycle 

FIG. 4 illustrates a more detailed depiction of the management of the object itself. The servers and other 

applications-server portion of such a system as shown in 65 aspects of the Platform are described in more detail below. 

FIG. 3 illustrating the business applications platform system However, a general overview of a preferred embodiment of 

of the present invention. the invention is first described. 



02/02/2004, EAST Version: 1.4.1 



US 6,643,652 B2 



(1) General Overview 

The technology used as part of the system currently is, 
and will be, able to interface with many other industry 
standard software programs to make the exchange and flow 
of data easy and accurate. 

The system is predominantly web-enabled, which extends 
its use to all industry professionals connected to the Internet. 
The Platform provides a unified set of interfaces, an appli- 
cation Framework, that encompass Business Object 
development, Web-application development, external con- 
nectivity development, and information distribution devel- 
opment. 

The system is predominantly based on object-oriented 
programming principles is described in "Object-Oriented 
Software Construction" by Bertrand Meyer, Prentiss-Hall, 
1988, ISBN 0-13-629049-3 and the Sun Microsystems™ 
developed JAVA™ systems described in, the, following pub-, 
lications: 

Enterprise JavaBeans Specification, vl.l (can be found at 

//java ^un.com/products/ejb/docs.html) 
Enterprise JavaBeans, Richard Monson-Haefel, O'Reilly. 
Enterprise JavaBeans: Developing Component-Based 

Distributed Applications, Tom Valesky, Addison- 

Wesley. 

Enterprise JavaBeans Developer's Guide (Beta \fersion) 
at 

//developerjava.sun.conVdeveloper/earlyAccess/j2sdkee/ 

doc-beta/guides/ejb/htm VTOC.html 
J2EE Application Programming Model (Beta Release), at 

//developerj ava. sun.com/developer/earlyAccess/ 

j2sdkee/download-docs.html 

all of which are incorporated fully herein by reference. 
The system makes use of some third party modules 
which are described in more detail below also. The 
terminology as used and described in these refer- 
ences for object, class, inheritance, component, 
container, bean, JavaBean, EJB, etc., are well known 
in these arts and are used herein generally without 
definition except where a specific meaning is 
assigned to a term herein. 
Overview of the Platform Architecture 
The following describes an overview of the preferred 
embodiment of the SABA architecture, and includes: 
A discussion of the system-level architecture and the 
modules that comprise the SABA system. This includes 
a high-level overview of each module, and lists the 
principle interfaces and functionality defined by each 
module. 

A discussion of the application-level architecture, cover- 
ing both the application-level architecture as exposed to 
different categories of users and some of the core 
business objects and their relationships. 

Referring now to FIG. 5, in the preferred embodiment, 
Saba's architecture consists of four layers of APIs: 

1. The Platform layer 501 provides underlying infrastruc- 
ture for enterprise applications, including standards- 
based functionality for persistence and distributed 
logic, application integration, content generation, and 
metadata queries. 

2. The Core Services layer 503 is a module that provides 
a set of common functionality for enterprise applica- 
tion. It includes services such as security, 
internationalization, and reporting. 

3. The Common Business Objects layer 505 is a module 
that defines a set of business objects shared across all 
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SABA applications. It includes objects such as Party 
and Plan. Vertical applications may each also contrib- 
ute a set of common business objects. 
4. The Applications layer 507 provides objects and ser- 
vices particular to a given application. There are mul- 
tiple modules contained within the Applications layer, 
including modules for Learning 525, Content 527, 
Performance 529, and Sales & Marketing 531. The 
specific applications modules indicated are shown by 
way of example. 
In the preferred embodiment, applicants have standard- 
ized their APIs around Session Bean Managers, interfaces 
that expose a common set of functionality. Each module 
therefore consists of several Session Bean interfaces. Thus, 
15 while SABA implements its managers using Entity Beans 
corresponding to persistent database objects, the interface as 
exposed to clients is solely mat of the Managers. 

This architecture also helps avoid circular dependencies 
by requiring that all dependencies be directed downwards. 
20 That is, a vertical application 507 may have dependencies on 
one or more sets of common business objects 505, but not 
on other applications. Similarly, common business objects 
505 may depend on core services 503, and on other common 
business objects 505, but not on applications 507. 
25 Platform 

The Platform model 501 defines applicants* application 
platform, on top of which all additional business logic and 
functionality are implemented. Platform 501 provides the 
full set of standards-based services required for building 
30 modem enterprise applications. 

Platform 501 consists of the following services: 
BDK (Business Development Kit) Business applications 
server 519 is Saba's EJB compatibility layer. It extends 
the standard Java business component model with 
SABA-specific enhancements, such as improved secu- 
rity and caching, as well as providing an abstraction 
layer to improve portability between EJB servers. The 
BDK 519 defines the following base interfaces: 
ISabaEntityBean — The abstraction of a persistent 
object 

ISabaSessionBean — The abstraction of a transactional 
service 

WDK (Web Development Kit) server 523 is Saba's web 
content generation engine. Using web standards for 
XML and XSL, it provides a customizable framework 
for decoupling data from presentation, and generating 
web content in a variety of formats, from standard 
HTML to WML. The WDK 523 provides the following 
base interfaces: 

IWDKObject — An object capable of serializing itself 
as XML 

Interconnect is Saba's application integration platform. 
Using XML and open standards for ERP integration, it 

55 provides a scalable and reliable solution for batch and 
period import, export, and monitoring. Interconnect 
defines the following base interfaces: 
IAccessor — Service for exporting objects from SABA 
I Importer — Service for importing objects into SABA 

50 IMonitor — Service for monitoring object changes 

Information Distributor Server 521 is applicants' query 
and delivery mechanism. Based on XML and RDF 
metadata standards, it defines a high-level query lan- 
guage and a set of agents for implementing information 

65 services. Interconnect provides the following services: 
MetadataRepository — A datastore for querying meta- 
data 



35 
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ImpoitAgent — An agent for generating metadata 
MatchAgent — An agent for locating metadata-based 
matches 

Delivery Agent — An agent for delivering match results 
Core Services 503 

The Core Services module 503 provides the common 
business services needed by applicants' system. These ser- 
vices are not specific to any industry, such as learning; 
instead, they provide the support and functionality required 
by applicants to meet generic enterprise requirements. 
Core Services consist of the following Session Managers: 
AuditManager — Tracks changes to objects in the system. 
Can return a complete history of changes, including 
date, username, and reason. 
BusinessRuleManager — Manage system business rules, 
that is, company policies defining the system's behav- 
ior in given situations. 

ComponentManager — Manage installed business objects 

for naming and instantiation. 
CurrencyManager— Manage currencies and exchange 

rates. 

DataDictionaryManager — Manage metadata about busi- 
ness objects. This metadata is used to generate user 
interfaces, specify constraints, and define object behav- 
ior. 

DomainManager — Manage domains. Domains are hier- 
archical groupings of business objects that can be used 
for a variety of purposes. 

FinderManager — Create and invoke Finders. Finders pro- 
vide a flexible mechanism for defining and executing 
database queries. 

HandleManager — Centralize access to managers avail- 
able to all business objects. 

il8nManager — Manage internationalization. Track infor- 
mation about locales, languages, timezones, and dis- 
play formats associated with business objects. 

LicenseManager — Manage software licensing. Track 
installed modules, license keys, and version numbers. 

LOVManager — Define lists of values. 

NLevelHierarchyManager — Support for nested folders. 
FoIderManager 
FolderElementManager 

NoteManager — Define notes (long text attachments). 

PreferenceManager — Set user preferences. 

SecurityManager — Manage user privileges. Assign per- 
mitted operations on objects to users and groups. 

ServiceHolderManager — Enable and disable common 
services (discussion, chat, etc.) 

ReportManager — Create and execute reports. Reporting 
engines currently supported include Brio and Crystal 
Reports 7. 

LetterManager — Generate form letters. 
TaxManager — Calculate sales taxes. 
NouficationManager — Manage notifications. Associate 

actions, such as sending an email or executing a Java 

method, with predefined system and periodic events, 
ActionManager 

AttachmentManager 

EventManager 

Par am Manager 

RecepientManager 

TextBlockManager 
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UserManager — Manage user preferences and allow used 

to switch between roles. 
Common Business Objects 

The Common Business Objects module 505 defines the 
5 set of business abstractions that are shared across more than 
one vertical application. These objects may be either generic 
business concepts, such as a Party, or shared concepts 
specific to Saba's application domain, such as Calendar. 
Common Business Objects 505 comprise the following 
10 Session Managers: 

AccountabilityManager — Used to manage a variety of 

relationships, such as reporting and organization 

membership, between entities in the system 
CalendarManager — Manage calendars and schedules. 
15 CorporateCalendarManager 

PersonalCalendarManager 
.... SfaCalendarManager . ....... 

SfaCalendarOwnerManager 

CheckListltemManagcr 
PartyManager — Manage entities within a business. 

Includes employees, clients, companies, departments, 

and business units. 
LocationManager — Manage locations, including 
25 addresses and contact information. 

RoleManager — Manage a function/job type within the 

value chain. 

PlanManager — Manage plans, that is, proposed course of 
actions. 

30 ProfileManager — Manage profiles, that is, comprehensive 
histories, goals, and plans for entities within a business. 

ValueChainManager — Manage value chain relationships 
between entities in an extended organization. 

Learning 

35 The exemplary Learning module 525 within the Applica- 
tions layer 507 defines the services used to build learning 
management systems. It provides APIs for defining learning 
offerings, which include classes, courses, on-line learning, 
and physical inventory, registering for and consuming 
40 learning, and tracking transcripts, certifications, and other 
results of learning. 

The following Learning Session Managers are delivered 
as part of Common Business Objects 505: 
45 CatalogManagcr — Browse a learning catalog. 

OfferingTemplateManager — The core abstraction of a 

learning intervention. 
The following Learning Session Managers are only avail- 
able with the Learning application: 
50 CertificationManager — Track certifications. 
CertificationAction Manager 
CertificationCompetencyManager 
HeldCertificationManager 
LearningManager — Manage learning offerings. Extends 
55 the concept of offering templates to include managing 
delivery types and delivery modes, offering instances, 
audience types, and offering modes. 
AudienceTypeManager 
DeliveryManager 
60 DeliveryModeManager 

EquivalentManager — Defines equivalent offering tem- 
plates. 
OfferingActionManager 
OfferingManager 
65 OfferingPolicyManager 

OfferingTemplateDeliveryManager 
ProductGroupMaoager 
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RosterManager 
PrerequisiteManager 
LearningResourceManager — Manage resources used by 
classes, such as classrooms, faculty, and equipment. 
InventoryManager 5 
Qualified! nstructor Manager 

RegistrarManager — Request and order a learning 
resource. Includes shipping and registration informa- 
tion. 

CourseRequestManager 10 

PackageOrderManager 

PricingManager 

RegistrationManager — Track completion and grading of 

learning offerings 
Content 

The Content module 527 within the Applications layer 
•507 defines the services used for all forms on on-line 
learning. It includes creating and launching WBT and VOD 
courseware, virtual classrooms, testing and assessment, 
community services, and analysis and tracking. 

The following Content Session Manager is delivered as 
part of Common Business Objects: 

ContentHolderManager — Allows any business object to 

be a content holder 25 
CourseContentManager — Associate content such as 

attachments and exams with learning offerings. 
The following Content Session Managers are only avail- 
able with the Content application: 

ContentManager — Manage learning content. 30 

TestManager 
AnalysisManager — Analyze test results. 
Communit yManager — Create and manage learning com- 
munities. 

Performance 35 
The Performance module 529 within the Applications 
layer 507 defines the services available for managing human 
performance. It includes competencies and goals. 

The following Performance Session Managers are dcliv 
ered as part of Common Business Objects: 

CompetencyManager — Assign competencies to roles, 
entities, and learning resources. Includes 
CompetencyHolderManager 

CompetencyProviderManager 45 
OfferingCompetencyManager — Associate competencies 

with offering templates and find learning interventions 

that provide competencies. 
The following Performance Session Managers are only 
available with the Performance application: 50 
Advanced competency definition, manipulation, and 

analysis, including: 

Competency AnalysisManager 

CompetencyGroupManager 

Competency MethodManager 55 
CompetencyModelManager 
GoalManager — Manage and track goals. Includes assign- 
ing goals and observations on goals. 
Goal Lib raryManager 

GoalObservationManager 60 
GoalStateManager 
Sales and Marketing 

The Sales and Marketing module 531 within the Appli- 
cations layer 507 defines the services available for the 
running the finances and logistics of a learning content 65 
provider. It includes the purchase of learning resources and 
tools for managing sales and marketing campaigns. 



40 



The following Sales and Marketing Session Managers are 
delivered as part of Common Business Objects: 

OrderManager — Generate orders. Includes invoicing and 
shipping options. 

PurchaseManager — Track the pricing of learning 
resources. Includes getting and setting prices and man- 
aging price lists. 

The following Sales and Marketing Session Managers are 
only available with the Sales and Marketing application: 

AccountManager — Manage client accounts. 

Advanced order management, including: 
TrainingUnitManager 
PurchaseOrderManager 

MarketingManager — Manage marketing campaigns. 
RoyaltylnfoManager 
ShipperManager 
- SalesMktManager — Order a learning resource. -Similar 
functionality to RegistrarManager, but designed for use 
in a call center to fulfill external orders. 

TargetMarketManager — Manage target markets and asso- 
ciate them with offering templates. 

TerritoryManager — Manage territories. 

Applications Architecture 

An exemplary version of an application architecture 
which can make use of applicants* invention could consist of 
four distinct applications that interoperate to provide a 
complete Human Capital Development and Management 
solution. Each of these applications is based around a core 
set of metadata; the applicants* architecture's value lies in 
the effective management of this metadata. The diagram in 
FIG. 6 describes this core metadata and how it is employed 
by different types of users in this exemplary implementation 
of this architecture. Those skilled in the art will recognize 
that this architecture can be used with various other kinds of 
applications systems, such as: financial product sales & 
marketing systems; retail store management systems; vari- 
ous kinds of maintenance & repair management & dispatch 
systems; etc. 

Referring now to FIG. 6, SABA Learning manages Cata- 
log Metadata 609 that describes a set of available learning 
interventions and Profile Metadata 611 that describes a 
learner in the system, including learning history and enroll- 
ments. 

SABA Performance manages Profile Metadata 611 that 
describes individual and group goals, competencies, and 
development plans. Together, the Profile Metadata 611 in 
Learning 607 and Performance 605 provide a complete 
description of the human capital in an extended organiza- 
tion. 

SABA Information 603 and SABA Content 601 manage 
metadata about a variety of on-line resources. SABA Infor- 
mation 603 uses this metadata to construct information 
services targeted to individual's information needs, whereas 
SABA Content 601 uses this metadata to manage learning 
content throughout its lifecycle and construct intelligent, 
reusable Learning Objects. 
Users work with this metadata as follows: 
Individual learners 619 query Learning Metadata (that is, 
the learning catalog) 609 to locate appropriate learning 
interventions. The system uses Learning Object Meta- 
data 613 to deliver and track learning interventions and 
updates the Profile Metadata 611 as appropriate. 
Team managers 621 work with Profile Metadata 611 to 
define, update, and track progress towards goals. They 
can analyze the metadata to identify problem areas and 
generate plans for meeting their goals. 
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Learning providers 617 use import and administration contains mechanisms to manipulate various kinds of display 

tools to create and update Catalog 609 and Learning style sheets, to generate and execute web links, to manage 

Object Metadata 613. dynamic content generation and dynamic generation of 

One of the principal tasks users perform in such a system Javascript, all of which is described in more detail below in 

is finding performance interventions — resources and ser- 5 the section on the Interface Server/WDK 417. 

vices that can be applied to improve human capital perfor- These servers and related facilities and others are 

mance. The diagram in FIG. 7 details the business objects described in more detail below, 
that support this process and their relationships. 

There are multiple, complementary mechanisms for iden- Operating Environment 

tifying interventions. 10 

Competency gap analysis can be applied to either an The environment in which the present invention is used 

individual's goals 713 or roles 715. The analysis compares encompasses the use of general purpose computers as client 

the required competencies for reaching a goal 713 or filling or input machines for use by business users of various kinds, 

a role 715 (either held or targeted) to actual held compe- includin g clerksu D^na^ej^eacbeis m jand/or SY &tem&admin- 

tencies and generates a competency gap 721. Learning is istrators. Suc h client or in put-machines may he enupleH to 

interventions (offerings 723) that fill the competency gap me TntemeT7sometimes refe rxed-to-as-the, "Web") through 

721 are the identified. A variety of other intervention types telecommunications channels which may include wireless 

* are' planned, including mforniation 733 and" com devices and systems as well, 

services 735. _ _ , 

Certification gap 719 analysis compares a role's certifi- 20 S ° me of * c el ^ ments . Intemet ' n& *" or * 

cation requirements associated to the actual learning profile configuration arc shown in FIG. 1 wherein a number of 

of the individual in the role. It then identifies the quickest chcnt machines 10 ? P 055 * 1 * " 1 br f ch officc of a Ur & c 

certification track to completion and recommends appropri- ^crpnse, a manufacturer, a financial enterprise, etc. are 

ate learning offerings 723 from the catalog. sh ^ fonncctod to a GatewayMb/mimel-server/etc. 106 

Having described an exemplary application we now 25 w ^ ch » itsdf^con^ 

describe the invention in additional context. internet semc^jPic^ CISP) co nn e ction l(W^spnoWn 

In a preferred embodiment, the Platform can support both are f** possible clients 101, 103 possibly used by other 

Application and Business component development, as well application systems users or interested parties, similarly 

as integration with development tools, connectivity to exter- COrme f ed to the 1Dtemet 107 via an connection 1<*, 

nal systems (import/export/exchange), and information 30 with these units communicating to possibly a home office via 

delivery. The architecture of the present invention adopts a an ISP connection 109 to a gateway/tunnel-server 110 which 

three-tier model and is shown in the diagram in FIG. 3. In ^ «>rm«ted m to vanous enter^ application servers 

FIG. 3 a tier 1 web user 301 is connected electronically to U3 ' ™ wmch . cou d * f ,DD ^ c c d 

a tier 2 web server 305 which is connected to a tier 3 ^™ter 115 to various local clients 116, 117, 118. Any of 

applications server 307. Also in Tier 1 a dedicated user 311 35 *™ a m > U3 > 114 could funcUon as a server of the 

may be directly connected to a tier 3 applications server 307. P reseD < mventlon • » m ™ descnbed ^ 1 user 

And the tier 3 applications server 307 may be connected to Sltuated at of th , ese clien ! n ? achlDes would M ™"y have 

a database management system 309. ? ™ autfa priged user of the system_as descnbed more 

Referring now to FIG. 4, the tier 3 applications server 307 Uy below * 

is expanded in FIG. 4 to illustrate the Business Applications 40 An embodiment of the Business Applications Platform 

Platform 415 of the present invention. In FIG. 4, the System of the present invention can operate on a general 

Platform contains an Interface Server 417, an Information purpose computer unit which typically includes generally 

Server 419, an Interconnect Server 423 and a Business the elements shown in FIG. 2. The general purpose system 

Server 421. All of these Servers 417, 419, 421 and 423 may 201 includes a motherboard 203 having thereon an input/ 

physically resign on the same hardware platform (such as a 45 output ("I/O") section 205, one or more central processing 

UNIX box or a Microsoft™ NT™ platform), or each server units ("CPU") 207, and a memory section 209 which may or 

may reside on a separate hardware box, or any combination may not have a flash memory card 211 related to it. The I/O 

of servers and hardware boxes. Each of the servers may have section 205 is connected to a keyboard 226, other similar 

included a JAVA Virtual Machine™ and the related runtime general purpose computer units 225, 215, a disk storage unit 

support. The electronic communications between these serv- 50 223 and a CD-ROM drive unit 217. The CD-ROM drive unit 

ers may use the XML protocol (409, 425, 427) with each 217 can read a CD-ROM medium 219 which typically 

server having services for translating XML into the parti cu- contains programs 221 and other data. Such programmed 

lar Applications Programming Interface (API) language computers may also be connected electronically to database 

required by the server and for translating its internal lan- systems such as those available from Oracle™, Sybase™, 

guage into XML prior to transmission to another server. In 55 Informix™, SQLServer from Microsoft™ and the like, 

a preferred embodiment, all of these servers arc contained in Logic circuits or other components of these programmed 

a single tier 3 platform, and may communicate with each computers will perform scries of specifically identified 

other directly without the necessity of changing the inter- operations dictated by computer programs as described more 

facing protocol format. The ^JnteifacsLJk>iy£L_417^ (also fully below, 

alterna tively designated herein as the WDK), com municates 60 

throug h a web^ ejver 40 5 viaj heinternet-403.to,web_clients Detailed System Description 
4 01 via^the HTML p rotocol. The Interf ace ServeM 17, also 

may communicate to a directly conne cted clienPW)7 v ia The Platform system of the present invention is now 

other protocols such as XSL/XSLT etc., and may commu- described in more detail. In general a preferred embodiment 

nicate to Personal Data Assistants 411 such as cell phones or 65 with a presendy known best mode for making and using the 

Palm Pilots™ or other such wireless devices using wireless system is described. Alternative embodiments are similarly 

protocols such as WAP/WML, etc. The Interface Server 417, described for various parts of the Platform system. 
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Business Applications Server/BDK 
Preferred Embodiment 

The following description of the BDK Business applica- 
tion server covers the presently preferred embodiment and 
the presently known best mode for making and using it. This 
section is followed by a further description of an alternative 
embodiment which may include features in addition to or in 
place of those in the preferred embodiment. 

1. Overview 

The Business Development Kit applications server 
(BDK) component of the Platform provides a supporting 
framework for business objects. A business object is a Java 
object with persistent state that represents some entity in a 
business application, such as an employee or company. 

Specifically, the BDK provides a persistence framework 
for saving and restoring object state and a set of core 
services for. performing a variety of useful. operations, on 
business objects. 

2. Persistence Framework 

The persistence framework defines a common code path 
used to create new objects, restore and update existing 
objects, delete objects, and find objects. The code path 
consists of a set of Java code and database stored procedures 
to construct and verify object data and SQL commands to 
save and restore information using a relational database. 

The persistence framework is highly flexible because it is 
metadata-driven. For each class of object, the system pro- 
vides a set of metadata — data about data — that defines the 
class* properties and behavior. This means that the data used 
to determine the behavior and characteristics of specific 
classes and instances of business objects is stored as distinct, 
editable information, rather than being hard-coded into the 
logic of the system. The persistence code itself is part of the 
metadata, that is, the SQL commands for save, restore, etc. 
are stored as metadata, not in source code. As an example 
benefit, it makes applications much easier to port between 
databases because only the metadata for the SQL needs to be 
changed; no source code needs to be changed and recom- 
piled. 40 

Use of metadata allows the system to be configured and 
otherwise modified by different clients for different 
deployments, resulting in unique runtime behavior of the 
system. Object properties that can be customized range from 
the labels used to display object information, to the type of 45 
data validation performed, to the amount of custom infor- 
mation associated with each object. 

A unique feature of the persistence framework is its 
support for an arbitrary amount of custom information, 
stored in what is known as "custom fields." Experience has 
shown that predefined business objects typically do not 
express the full set of data a given customer may wish to 
track, and that this data varies from customer to customer. 
Custom fields provide a way for different customers to 
uniquely extend the data stored with a class of business 
objects. In the current implementation, customers are pro- 
vided with a set of five "custom fields" that can be searched, 
and an unlimited number of "extended custom fields" that 
cannot be searched, but provide additional data validation 
for date and numeric values. Again, the code to save and 
restore custom fields is all driven off metadata. 

As an example of the persistence framework's operation, 
a user of the system may attempt to create a new employee 
by specifying the employee's first and last name, social 
security number, starting salary, and date of birth. The 
persistence framework performs the following operations to 
save this data as a new "SabaPerson" business object: 



Uses metadata settings about the "first name", "last 
name", "ssn", and "birth date" properties of a "SabaP- 
erson" to determine the data validation to perform. In 
this case, the metadata settings may instruct the frame- 
work to verify that values are provided for first name, 
last name, and ssn, that starting salary is greater than a 
fixed numeric minimum wage value, and that birth date 
is a valid date. 

Uses metadata to obtain and execute a database stored 

procedure named "tpp_person ins" that takes values 

for first name, last name, ssn, salary, and birth date as 
parameters and inserts these values into a database 
table named "tpL^person." 

2a. The Metadata Store 

In the preferred embodiment the meta-data store contains 
the definition of each type of object in the system, its 
attributes, and some basic -properties of those attributes.-- 
Further, for each type of object, it contains a reference to the 
methods to invoke, to insert, update, delete or fetch a given 
instance of that object from the persistent store. 

The Metadata store consists of the following tables: 

1. fgt_dd__class 

Every business object in the system is registered in this 
table. This table also describes basic properties of objects. 
fgt_dd_class has the following columns: 
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Column Name 


Type 


Rq? Description 


Id 


Char (20) 


The identifier of the object. 


Ui_name 


Vaichar2 


This is the display name of 




(255) 


the object and generally used 
to paint UI as well. 


Description 


Varchar2 


Meaningful description of the 




(255) 


object and its function. 


Enumber 


int 


Unique number for each 
object 


Insert_spid 


Int 


Method call for inserting a 
new instance of the object 
Foreign key to mesg_id 
column of fgt^mesg_table. 


Update spid 


Int 


Method call for updating an 
existing instance of the 
object Foreign key to 
mcsg_id column of 
fgt_mesg_table. 


Delete_spid 


Int 


Method call for deleting an 
instance of the object 
Foreign key to mesg_id 
column of fgt__mesg_table. 


Sel_dct_j»pid 


Int 


Method call for retrieving an 
instance of the object based 
on its id. Foreign key to 

mesg id column of 

fgt_mesg_table. 


Finder_id 


Int 


Finder Id for invoking a 
default finder associated 
with the object 


Fixed_attr_ct 


Int 


Total count of the fixed 
attributes for the object. 


Attr_ct 


Int 


Total count of the attributes 
for the object This number 
is sum of all fixed and all 
custom attributes. 


Flags 


Char (10) 


Ten bit string describes the 
behavior of the object 
1st bit - Object can be 
displayed in the security 
screen for granting privs. 
2nd bit - This 2bit mask is 
set to see if reports or 
letters or both can be 
attached. 

3 ld bit - Obsolete. 
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-continued 



-continued 



Column Name 



Type 



Rq? Description 



Column Name Type 



Rq? Description 



ncxt_atti_enum 



Prefix 



Table. 



Int 



char (5) 



Vfcrchar2 
(25) 



Domain enum 



Java_class_name Vforchar2 
(255) 

Hlevel Int 



Parent_id 



Char (20) 



4* bit - Obsolete. 
5* bit - If the object is 
owned in nature and cannot 
exist without its owner. 
6 th bit - Obsolete 
7 h bit - If object can be 
customized bu end user. 
& h bit - If Object can have 
Extensible attributes of its 
own. 

E number to use for the next 
custom attribute that will be 
added to the object The 
install time value for this 
attribute is 10,000. 
This Sletter long string is 
"used in~ generating 'ids for 
the object This string is 
prepended to the number 
generated by the sequence. 
This is the name where the 
object is stored. The 
sequence, methods are also 
named based on this. 
This is denonnalized data and 
shows the enumber of the 
Domain attribute. 
The java class name of the 
object 

The level of the object in 
the object hierarchy. 
In case of hierarchical 
object's it stores the parent 
object's id 



5 Enumber 



10 



Int 



Col name Varchar 

(255) 



Ui name 



Varchar (255) Y 



20 



description Varchar (255) 

Attr_type Int 

list_of_vals OBJECTTD 

25 

min_val Int 

30 max_val Int 

defeult__val STR 



As an example, the following are the values for a class of 
business object representing domains: 35 



id 


ui name 


description 


enumber 


insert_spid 


ddclsOOOOOO 
000001095 


Domain 


Hierarchal 
Domain 


195 


105(50 


update_spid 


delete_jspid 


sel_deLjpid 


finder_id 


flxed_attr_ct 


10562 


10561 


10563 


15710 


14 


attr_ct 


flags 


next_attr_ 
enum 


prefix 


tablc_name 


14 


1100001100 


100000 


domin 


fgt_domain 


domain. 


.enum java. 


_class_name 


hlevel 


parent_id 




com.saba.busobj. 
Saba Domain 


1 





40 



Gtr_l 



Flags 



STR 



varchar (15) 



50 



2. fgt_dd_attr 

The attributes of each class of business object is stored in 55 
this table. This table also describes basic properties of each 
attribute. 



fgt_dd_attr has the following columns: 



Column Name Type 



Rq? Description 



Id 

Cid 



Char (20) 
OBJECTTD 



Y 
Y 



Unique identifier for an 
attribute. 

The object id, this 
attribute belongs to 



60 
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Required to be unique within 
a class. The code should use 
these numbers to refer to 
attributes rather than using 
the ID. Fixed ennmbers are 
ne«?gnpH in the range 1000— 
9999. Extensible attributes 
are allocated from 10,000 

onwards. The next attr_enum 

in the corresponding object 
record stores the next 
enumber available for this 
class. 

The column name in which the 
value of this attribute is 
stored. 

The name of the attribute, 
which is used for painting 
the UI. 

Description of the 
attribute. 

The number corresponds to 
the data type of the 
attribute. 

If the attribute vaL is 
selected from a list of 
values, then the id of the 
list is stored here. 
If its a numeric column, 
then the min allowable value 
if any. 

[f its a numeric column, 
then the max allowable value 
if any. 

Default value to use for the 
attribute when an instance 
of the object is created. 
This generation formula for 
those attributes whose 
values have to be generated 
on the creation of the 
object The generation is 
driven by the generation bit 
In the flag. 

1" bit -> The required 
bit 

2 nd bit -> Reference bit is 

set if attribute points to 

another object 

3 rd bit -> LOV bit is set 

if its values must come from 

fixed list of values. 

4th bit -> This two bit 

mask describes the type of 

the attribute. 

5th bit -> Ed bit is set if 

its an Id column. 

6th bit -> Generation bit 

is set if the value need to 

be generated during the 

creation of an object 

7lh bit -> Customization 

bit This 4bit mask says if 

label, required or 

generation can be customized 

by end user. 

8th bit -> Audit bit 

9th bit «> Obsolete 

10th bit -> Obsolete 

ll* bit => This bit 

describes the type of the 

custom attribute. 

12 th bit -> Domain' bit is set 

if the attribute is domain 

id. 

13 a bit -> set if Default 
value can be changed by 
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Column Name Type 



Rq? Description 



user. 

14* bit ■> set if Minimum 
value can be changed by 
user. 

IS* bit ■> set if Maximum 
value can be changed by 
user. 



18 
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As an example, the following are some of the attributes 
defined for the domain business object: 



fgt_mesg table has the following columns: 



Column Name Type Rq? Description 

Mes&_id Int Y This is the message id for 

the SQL statement group. 

Mesg_seq Int Y Since the SQL statements can 

be greater than 255 chars 
which is the length of the 
mcsg_text columns. This 
column tells the sequence of 
this SQL statement in the 
group. 



id 


cid 


c number 


col_name 


ui_name attr_type 


flags 


ddatrOOO 


ddclsO 


1000 


id 


ID 8 


100011000 


0000000 


00000 








000000 


02991 


00000 
1095 










ddatrOOO 


ddclsO 


1001 


time stamp 


Time Stamp 4 


100000000 


0000000 


00000 








OOOOOO 


02992 


00000 
1095 










ddatrOOO 


ddclsO 


1002 


name 


Domain Name 4 


100000100 


0000000 


00000 








000100 


02993 


00000 
1095 










ddatrOOO 


ddclsO 


1003 


description 


Description 7 


000000300 


0000000 


00000 








000100 


02994 


00000 
1095 










ddatrOOO 


ddclsO 


1004 


customO 


customO 7 


000100300 


0000000 


00000 








010100 


02995 


00000 
1095 











3. fgt__mesg_Jable 

This table stores the actual SQL code used for object 40 
persistence. In the case of insert, update, and delete methods, 
typically these are calls to stored procedures containing 
additional business logic in addition to database calls. 

45 

Long SQL statements are stored in multiple rows, which are 
then reconstructed on-the-fiy by the persistence layer. 



-continued 



Column Name 


Type 


Rq? 


Description 


Mesg_texl 


Vfcrchar 


Y 


The text of message. 




(255) 







As an example, the following are persistence calls for the 
domain business object. Note from the sample data above 
that 10563 is the code for retrieving an object, 10560 for 
inserting an object, and 10562 for updating an object. 



mesg_Jd mesg__Beq mesg_text 



10563 


1 


select d.id id, d.time_stamp is, d.name 
dname, ^description descr, d .customO cO, 
d.customl cl, d .custom 2 c2, d.cusiom3 c3, 
d.custom4 c4, d.created_on cron, dcreated_by 
crby, cLupdatedL-on upon, d.upd 


10563 


2 


ated_by upby, dparent_id pid, parent name 
parent from fgL_domain d, fgt^domain parent 
where did - @001 and dparent_id - 
pareuUd(+) 


10560 


1 


begin fgp_domain_ins (@O01, @002, @003, @004, 
@005, @006, @007, @008, ©009, @010, @011, 
@012, @013, @014, @015); end; 


10562 


1 


begin fgp_domain_upd (@001, @002, @003, @004, 
@005, @006, @007, @008, @009, @010, @011, 
@012, @013, @034, @015); end; 
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Notice that the SQL references the actual table used to 
store domain data, fgt_domain (described in detail in the 
section on security). 

The fgp_domain _ins stored procedure is PL/SQL code 
defined as: 

create or replace procedure fgp 33 domain_ins 



create or replace procedure fgp_domain_ina 
( 

xid char, 

xtime_fftamp varchar2, 

xname varchar2. 

xdescription varchar2, 

xcustomO varchar2, 

x custom! varchar2, 

xcustom2 varchar2, 

xcustom3 varchar2, 
xcustom4 t varchar2, 

xcreated_on date, 

xcreated_by varchar2, 

xupdatcd_on date, 

xnpdated_by varchar2, 

xparent_id char, 

xnewts varchar2 
) 



begin 



/* validating that the parent of a node is not 
itself •/ 

if (xid Q xparent id) then 

raise_jpplication_error(-20698, 

return; 
end if; 

/* parent_id cannot be null except for the root */ 

if (xid o 'dominOOOOOOOOOOOOOOl ' and xparent_id is 

null) then 

raisc_application_ciTor(- 20699, "); 
return; 
end if; 

insert into fgt_domain ( 

id, time_stamp, name, ci_name, description, 
customO, custom 1, 

custom2, custom3, custom4, creatcd_on, 

created by, updated on, 

updated_by, parent_Jd) 
values ( 

xid, xnewts, xname, lower(xname), 
xdescription, xcustomO, xcustoml, 

xcustom2, xcustom3, xcustom4, sysdatc, 
xcrcated_by, sysdatc, 

xupdatedL_by, xparent_id); 
/• update the denormalized Mat tree tabic */ 
tpp_flaL_tree__relation(195, xid, null, null, 0); 
/* inherit a snapshot of the custom fields for all 

objects "/ 

insert into fgt__dd_domain_to_attr 

(ID, TIME_STAMP, DOMAIN_ID, ATTR^ID, FLAGS, 
LOCAl^FLAGS, ULNAME, MIN_VAL, 

MAX_VAL, DEFAULT_VAL, UST_OF_VALS, 

GEN_MASK) 

select *ddoat'|| 

lpad(ltrini (itiim(to_ciiM(fgL_a^d_domflin_to_aitr_seq.nextval))), 15, 

xncwta, xid, ATTR_ID, FLAGS, LOCAL_FLAGS, 
UL—NAME, MIN_VAL, 

MAX_VAL, D EFA U LT_ VAL, UST_OF_VALS, 

GEN_MASK 
from fgt_dd_domain_to_aUr 
where domain_id - xporent__id; 

end; 



Every SabaObject is expected to know which class it 
belongs to, and how that class is registered in the 
meta-data store. Thus each subclass of SabaObject 
stores a class identifier so that it can tell the system 
3 which entry in the meta-data store it corresponds to. 

Every SabaObject also stores a state flag that determines 
whether this is a new object, or it is an object that 
already exists in the data store. This state then deter- 
10 mines whether the object invokes an insert method or 
an update method during a save( ) invocation. 

Every SabaObject has an unchangeable, unique identifier 
that identifies that particular object in the persistence 
is store. The uniqueness of this identifier is guaranteed 
across the entire persistence store regardless of the type 
of object. 

20 Trie algorithm for save is then as follows: 



Look up the entry for the class of the object in the 
meta-data store. 



25 
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2b. Persistence Algorithms 

In a preferred embodiment all business objects that Saba's 
Application server manipulates are derived from a single 
base class called SabaObject The SabaObject class provides 
save, restore, and delete capabilities by implementing the 
persistence layer architecture. All subclasses of SabaObject 
then inherit this behavior and rarely if ever override it. 



65 



If the class is notfound, raise an error "Unknown Class". 
If (State-new) 

M=look up the method to call for inserting the object. 
Else /* State-update */ 

Molook up the method to call for updating the object 

Marshall all the attributes of the SabaObject into the 
appropriate data structure. 

Check each of the attributes against the rules set for its 
nullity, constraints. If any of the constraints are 
violated, throw an error. 

Lead the default values wherever necessary. 

Invoke M with that data structure. (1) 

For deletion, the basic process is identical, except that the 
invocation of the delete method only requires the unique 
identifier of the SabaObject to be passed in as its only 
argument. 

For restore, the algorithm is just slightly different and is 
as follows: 

Look up the entry for the class of the object in the 
meta-data store. 

If the class is notfound, raise an error "Unknown Class". 
M-look up the method to call for fetching the object. 
Invoke M(unique ID of SabaObject) 
Unmarshall all the attributes returned by M (2) 
In the presently preferred embodiment, the method invo- 
cation currently only supports invocation of database stored 
procedures although in alternative embodiments this will be 
extended to other types of persistence mechanisms. 

These stored procedures provide the actual intelligence of 
taking the marshaled arguments that come in, and storing 
them in specific fields in the database, and vice versa. Thus 
a combination of the meta-data store and the stored proce- 
dures create an abstraction layer that allows the base 
SabaObject to store all objects through a simple, uniform 
algorithm. 
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Fetch Methodl (Insert Method] | Update Method] | Delete Method] 



10 



The persistence mechanism thus created allows the trans- 
fer of various kinds of objects to database storage as shown 
below. 15 



|Objcctl| lObject 2| 



mm 
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Fig 1 Single object to Rg 2: Two objects to a 

a single table single table 



|Objectl| 





30 



Fig 3. Single object to 
two tables 



Fig 4: Object with calculate 

fields that do not physically 
exist in the table 



Object l| 



Fig 5: Object does not have 

denonnalized fields that 
exist in the table 



Individual messages are retrieved using a SQL command 
of the form: 

select mesg_id, mesg_seq, mesg_text from fgt_mcsg_ 

table where mcsg id-? order by mesg id, mesg__seq 

Query results are transformed into actual SQL code using 
the following method: 



private static String processMessage(ResultSet rSet) 
throws Exception, SabaException 

StringBuffer buf; 
String str, 

buf - new StringBuffer (rSct.getString(kMsgTextCol)); 
while (rSeLnextO !- false) 
{ 

String temp - rSetgetString(kMsgTextCol); 

buf.append (temp); 

} 

str - buf.toStringO; 
return str; 

Retrieved messages are also stored in a local cache for improved 
performance. 



22 



2c. Configurable Custom Fields 

In the preferred embodiment, the Saba persistence mecha- 
nism provides built-in support for configurable, runtime 
definable, custom fields for any object. 

The basic mechanism is extremely simple. An adminis- 
trative user interface is provided by which the meta-data 
definition of a given class can be extended by adding (or 
removing) custom attributes as needed. For each custom 
attribute, the user only needs to provide some very basic 
information about the type of the field, whether or not it is 
required, constraining minimum and maximum values for 
numeric fields, and a constraining list if the field is to be 
validated against a list of possible values. 

The Saba Object implementation then simply picks up 
these fields during its normal marshalling and unmarshalling 
of arguments. Further, the SabaObject also performs the 
basic checks for nullity as it would normally do. 

To save and restore the custom fields, the actual algo- 
rithms are extended from the ones shown earlier. In the case 
of insert or update the following additional lines are called 
after the line marked (1) in the algorithm shown earlier 

After invoking the basic method M 

Marshall all custom field data into the appropriate data 
structure 

Invoke the insert/update method for storing the custom 
data structure. 

In the case of restore, the following lines are added to the 
original algorithm after the line marked (2): 
Invoke the custom field fetch 

Unmarshall all custom field data and update the relevant 
fields in the SabaObject. 

The actual storage where the custom field data for any 
given instance is stored, consists of a single table as defined 
below. All the custom field data is stored as tag-value pairs 
in typed columns. 

Fgt_dd_custom 

This common table provides the storage area for all data 
stored in the extended custom fields for a given object. 



40 





Column Name 


Type 


Rq? 


Description 




Id 


OBJECTTD 


Y 




45 


owncr__id 


OBJECT1D 


Y 


Which object this custom 








field is for. 




aUr_id 


OBJECTtD 


Y 


Refer to the attribute 
for which value is 
stored. 




attr_type 


INT 


Y 


Type of the custom field. 
This matches the ottr_type in 










50 








the fgt_dd_attr table and is 
a denormalization of the 
same. 




Num vnluc 


Number 


N 


Value is stored here if it is 
Numeric type 




Str_value 


Varchar 


N 


Value is stored here if 


55 




(255) 




it is String type 




Date__value 


Date 


N 


Value is stored here if it is 
Date type 



3 Core Services 
60 BDK also provides a set of core services to perform useful 
operations on business objects. Some of these services 
include: 

Security. BDK provides extremely fine-grained security 
control to control whether specific users have privileges 
65 to perform operations such as creating or viewing a 
particular class of business object. The system is unique 
in that it provides a flexible model of security roles and 
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security lists to assign a set of privileges to distinct a. SabaObject API 

groups of users, and it employs a scalable notion of One Java API is a proprietary "SabaObject" interface to a 

domains to differentiate among sets of business objects. business object. A SabaObject is a Java class defining a set 

The security model is explained in detail in a separate of operations common to all business objects, including the 

section below. 5 abililv 10 6 et and 561 properties using a variety of data types 

, . , . .. „ and the ability to save and restore an object's state. Specific 

Auditing. BDK provides the ability to track the history of business objecl classes can SabaObject to add 

all changes to an object, including the date of a change, functionality and business logic appropriate to that class, 

the identity of the user making the change, and a ^ Java mtcr f aC e for SabaObject is the following: 
justification for the change. 1Q 
Internationalization (il8n). BDK provides utilities for 

allowing business objects to be internationalized. Inter- — - ^ 

nationalization is a standardized process wherein mes- public class SabaObject { 

sage content, money amounts, dates and various other * SabaObject Constructor 

culture Specific data are kept in separate files in Order 15 * Creates a new empty Saba object is the context of the 

to permit an easy change from one countries language session. 

and cultural rules to another. This comprises both *(. 0 , ^. . . . v . 

. . , . . . . i . , , public SabaObtectrString BessionKey); 

storing values of business objects in multiple languages - r mcthod5 to 8ct attributc vaiucT« ^cfect'datat^p« ' 

and supporting multiple formats for date, currency, and */ 

Other data types that vary among countries. 2 0 public void setAttr\&l(String attrName, Boolean attrVal); 

^ n _„ . , r public void aetAttrValfString attrName, Timestamp 

Concurrency. BDK provides concurrency services for attrVal); 

Controlling overlapping Write Operations on multiple public void 8etAttrVal(String attrName, Integer attrval); 

instances Of an Object, While permitting multiple reads public void sctAttrVal (String attrName, BigDecimal 

at the same time. This is achieved via comparison of an attrVy ^' .. . 

, \ . public void setAttr\fel(Stnng attrName, String attrVal): 

instance-specific timestamp when committing of an 25 pubUc void sctAttrValtString attrName, Object attrVa^ 

object's state to the persistent store is requested. The r methods to restore attribute values as different 

timestamp is updated whenever the state of an object is datatypes •/ 

altered and the object is successfully committed to ^ J! c & ^^^**f"*™l . 

. J J public String getStriEgAttrVal(String attrName); 

persistent Storage. public Integer getIntegerAttrVal(Struig attrName); 

Transaction Management. BDK provides two types of 30 public Timestamp gelllmestampAttrVal(String attrName); 

transactional services: procedural and declarative. In ^^^^^'^^ 

, - , , . i ■ . public Boolean getBooleanAttrVal(Stnng attrName): 

the former case, a developer explicitly marks the begin- /»* 

ning and end of a unit-of-work using BDK's API. In the * Gets a hashtable of the attribute values, 
latter case, a developer can associate a transactional 

attribute with a method, and the BDK's Transaction * P^ Uc Hashtablc e^ributeVWnes 0; 

Monitor keeps track of initiating and terminating . ^ dispIay Ubcl for ^ named attribute 

transactions, as well as executing a method within the */ 

SCOpe of an On-going transaction, based On run- time public String getAttributeLabel( String attrName); 

context ^ nvc * restore, and delete methods */ 

^ public void save0; 

Logging- BDK provides logging functionality that can be public void savc(SabaTransaction tr); 

used for capturing system state and operations in one or public void restoreO; 

more IOCS public void restore(SabaTransaction tr); 

public void delete 0; 

Notification. BDK provides the ability to send } 

notifications, such as emails or faxes, to predefined 45 ' 

categories of users when the state of identified business , n thc fcfrcd cmbodimcnt) „ t of a busiDCSS 

objects changes. For example everyone .subscribed to ^ {hc busincss objcct m±QT {dcs fouf J SQL 

a class may receive a page if the class is cancelled. statcmcnts oorreapoildillg J t0 ^on, deletion, insertion, 

Business Rules. In a preferred embodiment, for example, and updating of the object. Pointers to these statements are 

Saba's learning application provides a set of pre- 50 provided as part of the metadata for the object as stored in 

defined business rules that affect the workflow and fgt_dd_class. Tne first two (selection and deletion) types of 

behavior of various business objects in the system. The statements take a single bind variable, namely, the id of the 

BDK provides a mechanism to enable and disable these object. The other two take the id as well as all other attribute 

business rules. For example, a customer can configure values in the order declared in the metadata for that object's 

whether a manager's approval is required to register for 55 attributes in the table fgt_dd_attr. The order of retrieval of 

a class. Similar business rules can be handled for other attributes in thc selection statement must also match such 

types of applications. order. 

Notes. BDK provides the ability to associate arbitrary, Upon receiving a request to create an in-memory repre- 

free-form text, or "notes," with any business object in sentation of an object through the "restore( )" method, BDK 

the system. 60 retrieves the selection statement for that class of objects, 

4 Application Programming Interfaces binds the variable to the id of the object that is desired to be 

In the preferred embodiment, the BDK exposes Applica- restored, executes the statement, and fills in an instance- 

tion Programming Interfaces (APIs) for use in programming specific hashtable of attribute-value pairs with the values so 

the system. A variety of APIs with equivalent functionality retrieved. In addition, a standard SQL statement is executed 

are supported on top of the persistence framework. The 65 to retrieve the value of extended custom attributes, and the 

system supports both propriety and industry-standard forms results are again inserted in the aforementioned hashtable. 

of Java API, as well as XML-based APIs. For the "restore(SabaTransaction tr)" variant of this 
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operation, tbe execution of these SQL statements is done 4c. Session Manager APIs 

using the database connection contained in tr, the transaction The EJB model also has a notion of "session beans," 
argument. When executing the "delete( )" method, the object higher-level interfaces that represent business processes. In 
is marked for deletion. Upon a subsequent call to "save( )" the preferred embodiment, the BDK has standardized on the 
or "save(SabaTransaction tr),** BDK checks for the state of 5 use of session bean-based interfaces as its public API; these 
the object. If it is an object that has been marked for deletion, interfaces are known as "session bean managers," and are 
the deletion SQL statement as supplied by the business implemented using the lower-level entity bean APIs pro- 
object author is executed after binding the id, using the vided by the persistence layer. The BDK provides a 
database connection in the transaction argument for the SabaSessionBean base class that defines common session 
"save(SabaTransaction try case. Other possibilities upon 10 bean manager functionality, and a framework for several 
execution of the save operation are that the object instance categories of "helper classes" — additional interfaces used in 
is new, or it is an altered state of an existing object. In these conjunction with specific session bean managers: 
cases, the statements corresponding to insertion and I updat- Det ail-<epresent immutable detail information about a 
mg are executed, respectively, after the replacing the bind ^ business object 
variables with attribute values from the hashtable in the „ „ - . . 
order specified in metadata. In the case of insertion, BDK Handle— represent opaque references to a business object 
automatically generates. a,. unique id.for the.object that is .... Primitive— represent commonly used data structures,^ 
reflected both in the persistent storage and the in-memory such as addresses and full names 
representation. 4d - Interfaces 

Implementation of the setAttrVal( ) and 20 In me preferred embodiment, the BDK also provides 

get<type>AttrVal( ) involve setting and accessing values in XML-based interfaces for saving and retrieving business 

the hashtable, respectively, using the provided attribute objects; these interfaces provide the communication layer 

name as the key. getAttributeValues( ) returns a copy of the with the other Platform servers and components, 

object's hashtable whereas gelAttributeLabel( ) looks up the One XML format is known as "Saba Canonical Format" 

attributes' metadata and returns the label corresponding to 25 (SCF). It is an XML serialization of the data in a SabaObject. 

the chosen attribute. Th e Interconnect server system reads and writes SCF to 

4b. SabaEntityBean API implement the AccessorReader and ImporterWriter for the 

Another Java API is based on the industry-standard Enter- na ti ve Saba system; refer to the Interconnect server section 

prise JavaBean (EJB) model. This model has a notion of for more details. 

"entity beans" that provide the interface to specific business 30 An example fragment of an SCF document, representing 
objects. Accordingly, the persistence framework provides a a business object defining a specific currency, is: 
EJB-based abstract class, "SabaEntityBean" that imple- 
ments the javax.ejb.EntityBean interface. The SabaEntity- 
Bean class provides default implementations of the follow- _ . „ . > , ~~~ ... . _ " 

r . . y X * • v\« ✓ \ 35 <SabaObiect type- com. saba.busobi.Saba Currency 

mg methods: ejbAcuvate( ), ejbPassivate( ), ejbRemove( ), id="cmcy000000O0000000i" status^cristing^ 

setEntityContext( ), ejbCreate( ), ejbLoad( ), ejbStore( ), and oiamc dt:type»"string , '>us Doiiars<mame> 

unsetEntityContext/ ). Implementations of the ejbLoad( ), <time^tam P 

cjbStorca^Crea^^^ «^^™™™^^tZ^«-™>> 

selection, update, insertion, and deletion statements declared dt:type-"8tring">iioooooooo^/flflgp> 

as part of metadata (please refer to the discussion of the <^SabaObject> 

implementation of SabaObject's API). Other methods are 

implemented as empty stubs that can be overridden by a fa tbe preferred embodiment> another xm L i^ce ^ 

developer if desired. . the "IXMLObject" interface. An IXMLObject is a Java 

In addition to defining the bean class, to implement an object b , e of xtia]izi itse , f into ^ - XML repreS enta- 

EJB one also needs to define a corresponding remote tion The ^ handl ^ primitivc nelper objects ^ by 

.interface, a home interface and, for enuty beans, a primary beaQ ma aU j^,^, this inlerface . We 

key class. Tbe remote interface is tbe external world's view ^ ^ g , em ^ mese objects to , e d ic 

of the bean and is comprised of the business methods that the web ^ b ' the ^ ion ^ m ^ 

bean wishes to expose. The getters and setters for the bean s men xtiA]hiDg mc resulting objccts mt0 XMI4 refer to the 

attributes are also exposed through the remote interface. The for morc ^ils. 

home interface declares the life-cycle methods, such as those ^ 1XMLObject mtcrfac6 to me "Visitor" 

for creating, removwg or finding beans. desj ttem> Md js defined as foUows . 

In the preferred embodiment, the BDK provides two 
interfaces, ISabaRemote and ISabaHome, which a bean can 

extend for defining remote and home interfaces, respec- 55 

lively. The ISabaRemote interface extends the standard EJB public interface IXMLObject { 

interface EJBObject and provides the following sets of '** 

methnd * Accept a visitor. An implementation should ask the 

Visitor to visit each of its public elements (i.e., fields or 

void setCustomAttrVal(String attr, <type>value), and fi0 properties). 

<type>getCustomAttrVal(String attr) ] @param v[ait0I ^ ^ VUUor objcct 

for Boolean, Timestamp, String, Integer, Float, and V 

Double data types. The ISabaHome interface provides P" 0110 void aoccptXMLVisitor(rXMLVtsitor visitor) throws 

a layer of abstraction over the standard EJB interface XMLVisitorException; 

EJBHome. The BDK also defines a class SabaPrima- 65 . Qti the preferred tag name for this object 

ryKey (a thin wrapper around the String class) which * ©return the tag name to identify 
can be used by entity beans for defining primary keys. 
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-continued 



public String getHgNameQ; 



Note: a "visitor" object is one which has processes which represent an 
operation to be performed on the elements of an object structure. A visitor 
lets one define a new operation without changing the classes of the ele- 
ments on which it operates. Visitor objects and their operation and use are 
described in more detail at pages 331-344 of Design Patterns, by Gamma, 
Helm, Johnson. & Vlissides. Addison-Wcslcy 1995, ISBN 0-201-63361-2 
which are hereby fully incorporated herein byrefierence. Those skilled in 
these arts will recognize that various other implementations of these algo- 
rithms and concepts may be developed without departing from the spirit 
and functionality of this invention. Additional background information can 
be found in Enterprise JavaBeans Specification, vl.l (can be found at url- 
java.sun.com/prodiJcts/cjb/ docs.html), and in other sections of the book 
titled Design Patterns, by Gamma, Helm, Johnson, & Vlissides, Addison- 
Wesley 1995, ISBN 0-201-63361-2 which are hereby fully incorporated 
herein by reference.*" "* * * 

Alternative Embodiment 

An alternative embodiment of the BDK business appli- 
cations server may be described as follows, using the context 
of how a developer and user would use this portion of the 
system. In an alternative embodiment, the developer's use is 
outlined in the context of a BDK development kit which 
would be provided by Applicants for use in developing 
applications which can run on the Platform and by way of 
indicating some details unique to the Platform through a 
description of a use of the Business Development Kit 

In the alternative embodiment, the Business Server 
embodies a development kit framework which provides a set 
of interfaces and classes in the form of Java packages, 
identifies certain services that developers can rely on, and 
defines an application development model. The framework 
relies extensively on the server-side component model 
espoused by Java, namely Enterprise JavaBeans (EJB) com- 
ponents. Selection of EJBs as the server-side component 
model is driven in part by the requirements of reliance on 
open standards and backward compatibility. Using EJBs 
also enables integration with other Java 2 Enterprise Edition 
(J2EE) technologies such as Java ServerPages (JSP) and 
servlets that one would intend to use for web applications 
development Furthermore, a number of EJB-enabled appli- 
cation servers available in the marketplace could be used to 
deploy the components so developed. 

In the alternative embodiment, the development kit 
classes and interfaces, the services, and the application 
development model are discussed in greater detail in the 
next three subsections. 

Classes and Interfaces 

The BDK interfaces and classes address the following 
needs. 

1. Provide an additional layer of abstraction (by writing 
wrappers around base Java classes) to provide a richer 
level of functionality needed by SABA applications and to 
allow future modifications with minimal impact on the 
client application code. 

2. Expedite component development by providing default 
implementations (that can be overridden) of certain 
required interfaces in EJB. 

3. Define certain interfaces that must be implemented by 
classes used for specific purposes (an example is that a 
class must implement a certain interface if its instances 
are used in a JSP page). 

4. Define certain classes that are necessary to provide basic 
services, such as data partitioning and logging, as well as 
utility classes for expedited application development. 

5. To the extent possible, eliminate application server depen- 
dencies in areas where the EJB Specification is currently 
not vendor independent. 



In the alternative embodiment, the following discussion 
of is background for a discussion of the usage and types of 
EJBs within the context of the development kit described in 
more detail below. 

5 Metadata Support 

In the alternative embodiment, one of the facilities pro- 
vided by the development framework is that characteristics 
of business objects can be varied across deployment. For 
example, for an attribute, one can optionally specify whether 

10 it has a required attribute, the list of values (LO Vs) that the 
attribute can assume, its default value, and its minimum and 
maximum values. The values can be different across 
installations, as different customers have different require- 
ments. To achieve this flexibility, metadata about the busi- 

15 ness objects and their attributes is captured in the system. 
In the alternative embodiment, some of the metadata that 
is currently captured about a class or an attribute could be 
dynamically determined using the Java reflection API. 
Examples include the parent ID and attribute count for 

20 business objects and attribute type for an attribute. The Java 
reflection API provides classes Class and Field that can be 
used to retrieve such information. Furthermore, instead of 
building a hashtable-based infrastructure for storing and 
retrieving attribute values, one can use methods like set and 

25 get in the Field class to operate directly on the attributes, 
which are declared as member variables of the class. 

The classes Class and Field by themselves, however, may 
not provide the rich functionality needed by certain appli- 
cations. For instance, there is no way to indicate minimum 

30 and maximum values of an attribute in the Field class. Thus, 
what is needed is to create new classes that provide wrappers 
around Class and Field and capture the additional informa- 
tion. In the interest of consistency with previously used 
names while avoiding conflicts at the same time, two new 

35 classes maybe used: SabaPlatformClass (inherits from 
Class) and SabaPlatformAttribute (inherits from Field). In 
addition to the functionality provided by Class (e.g., for 
getting parent class), SabaPlatformClass provides for such 
additional functionality as domain-based attributes and get- 

40 ting fixed vs. extended custom attribute counts. Similarly, 
SabaPlatformAttribute provides functionality for LOVs, 
default value, and minimum and maximum values. (As we 
will discuss later, the classes SabaPlatformClass and Saba- 
PlatformAttribute themselves are beans — or, entity beans to 

45 be more specific — in this alternative embodiment system.) 
The classes SabaPlatformClass and SabaPlatformAt- 
tribute will not be used directly by users of business com- 
ponents (though developers of such components will use 
them). Typically, the user of these classes will be a class 

50 SabaPlatformObject. In some instances, SabaPlatformOb- 
ject will make use of the functionality provided by these 
classes as part of an operation (e.g., when setting the value 
of an attribute, SabaPlatformObject will use SabaPlatfor- 
mAttribute to determine the minimum and maximum value 

55 constraints). In other cases, SabaPlatformObject will del- 
egate an operation directly to one of these classes (an 
example would be retrieving the superclass of an object). 
SabaPlatformObject implements a set of methods for getting 
and setting attribute values that provide a centralized point 

60 for capturing the logic for such things as auditing and 
constraint checking, and are used by subclasses of SabaP- 
latformObject. 

In this alternative embodiment, a component user will not 
interact directly with even SabaPlatformObject. Instead, the 

65 component user will deal with a specialization of either a 
SabaEntityBean or a SabaSess ion Bean, which are discussed 
in the next subsection. 
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Beans 

In the alternative embodiment, components based on 
Enterprise JavaBeans (EJBs) will be a basic building block 
for developing applications using the BDK. Below we 
provide a brief overview of EJBs. Those skilled in these arts 5 
will understand that various books and documents on the 
"java.sun.com" web site provide additional details on this 
subject. There are two types of EJBs: 

1. Entity Beans, and 

2. Session Beans. 

Entity beans are used for modeling business data and 
behavior whereas session beans are used for modeling 
business processes. Examples of entity beans could be 
SabaClass (a training class, not a Java class), SabaPerson, 
and SabaRegistration. Entity beans typically would map to 
objects (tables) in the persistent data store. Behaviors asso- 15 
ciated with an entity bean typically would relate to changing 
the data in the bean. 

An example of a session bean could be SabaRegistrar, 
which uses the entity beans mentioned above and encapsu- 
lates the business logic associated with certain tasks, such as 20 
registering for a class. Session beans are not persistent, 
though changes in data of certain entity beans or their 
creation or removal could result from the actions of a session 
bean. A session bean can be stateful or stateless. A stateful 
session bean maintains state information specific to the 25 
client using it, such that results of invocation of a method 
may depend upon the methods invoked earlier on the bean. 
(An example of a stateful session bean would be 
SabaShoppingCart, which would keep track of items in an 
order as they are being added, to be followed by either 30 
placement of the order or clearing of the cart.) This is 
typically done by storing client-specific data in instance 
variables of a bean, which are then used by the methods to 
accomplish their task. A stateless session bean does not 
maintain any state specific to a client. An example of a 35 
stateless session bean would be SabaTaxCalculator, which 
provides methods for computation of sales and other taxes. 

In the alternative embodiment the development kit would 
provide two abstract base classes: SabaEntityBean and 
SabaSessionBean. (Whether a session bean is stateful or 40 
stateless is indicated in something called a deployment 
descriptor.) These classes implement the javax.ejb.Entity- 
Bean and javax.ejb.SessionBean interfaces, respectively. 
The intent is to provide a default implementation of certain 
required methods to enable rapid development of 45 
components, yet allow a component to override the default 
implementation of the methods it chooses. The SabaEntity- 
Bean class provides default implementations of the follow- 
ing methods: ejbActivate( ), ejbpassivate( ), ejbRemove( ), 
setEntityContext( ), ejbcreate( ), ejbLoad( ), ejbStore( ), and 50 
unsetEntityContext( ). Implementation of the ejbRemove( ) 
and ejbCreate( ) are discussed in the next subsection. The 
other methods in the list by default have an empty imple- 
mentation. The SabaSessionBean class provides default 
(empty) implementations of the first four methods in the 55 
preceding list^abaEntityBean inherits from SabaPlatfor- 
mObject and provides attributes common to all the entity 
beans, (such as namespace) and has a method to XML( ) that 
ensures that all entity beans will provide an implementation 
for serializing their data to an XML representation. In other 60 
words, SabaEntitybean implements an interface ISabaXM- 
LRenderable (explained later) and provides two conve- 
nience methods: findUsingRQL (String rql) and findUsin- 
gRQLURI (String URI) to locate specific entity beans using 
RQL. 65 

In addition to defining the bean class, to implement an 
EJB one also needs to define a corresponding remote 
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interface, a home interface, and, for entity beans, a primary 
key class. The remote interface is the external world's view 
of the bean and is comprised of the business methods that the 
bean wishes to expose. The getters and setters for the bean's 
attributes are also exposed through the remote interface. A 
developer must implement these methods by calling the 
getAttrval( ) and setAttrVal( ) methods available in SabaP- 
latformObject to take advantage of services like constraint 
checking and auditing. The home interface declares the 
life-cycle methods, such as those for creating, removing, or 
finding beans. 

The development kit provides two interfaces ISabaRe- 
mote and ISabaHome, which a bean can extend for defining 
remote and home interfaces, respectively. The ISabaRemote 
interface extends the standard EJB interface EJBObject and 
provides the following sets of methods: 
void setCustomAttrVal(String attr, <type>value), and 
<type>getCustomAttrVal(String attr) 
for Boolean, Timestamp, String, Integer, Float, and 
Double data types. The ISabaHome interface provides 
a layer of abstraction over the standard EJB interface 
EJBHome. The BDK also defines a class SabaPrima- 
ryKey (a thin wrapper around the string class) which 
can be used by entity beans for defining primary keys. 
One final interface defined in the BDK for EJBs is 
ISabaXMLRenderable. This interface extends the java.i- 
o. Serial izable interface and defines a single method, 
toXML( ). Only classes that implement this interface are 
eligible to act as return types of methods that are going to be 
invoked from a Java ServerPage. 

In the alternative embodiment the BDK would come with 
a few prepackaged beans. One is a stateless session bean 
named SabaPlatformLogm that can be used to authenticate 
a user. Another is an entity bean named SabaNameSpace, 
which encapsulates characteristics of a namespace, includ- 
ing its place in the hierarchy and the list of users who have 
access to entity beans in that namespace. The namespace is 
used for data partitioning and security purposes. 
Relationships 

Another area in which the BDK provides support is 
relationships amongst entity beans. In an object model, 
relationships between different classes are arranged in four 
categories: inheritance, association, composition, and aggre- 
gation. During implementation, the inheritance relationship 
is captured by extending a subclass from a superclass. The 
other three types of relationships entail constraints between 
the classes being related. For instance, a composition rela- 
tionship implies commonality of life span (i.e., destroying 
the "whole" should result in destruction of the 
"components") and an association relationship implies ref- 
erential integrity constraints (i.e., creating an instance of a 
class which refers to a non-existent interface of another class 
is not permitted). In an alternative embodiment, such rela- 
tionships can be captured through constraints in the data- 
base. 

In the alternative embodiment, the BDK will provide a 
Sab a Relationship class, that has attributes for the name of 
relationship, the type of relationship, the source class and 
attribute, and the destination class and attribute. The 
Saba Relationship class will encapsulate lifetime manage- 
ment constraints implicit in each of the different types of 
relationships. Thus, if an object is being removed and it is 
declared to have compositional relationship with some other 
objects, the SabaRelationship class will ensure the removal 
of the related objects. Similarly, when creating an object, the 
SabaRelationship class will ensure that referential integrity 
constraints are being satisfied. The SabaEntityBean class 
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will delegate calls to the SabaRelationship class within its Id the following paragraphs we discuss the various services 

ejbRemove( ) and ejbCreate( ) methods. Any implementa- that an application developer can rely on and how these 

tion that a component developer provides for these methods services might be used, 

for a specific bean would have to call super.ejbRemove( ) or Distributed Components 

super.ejbCreatc( ) as appropriate. 5 One of the key ingredients for building scalable systems 

In the alternative embodiment, an attribute capturing the is the ability to distribute components. In the EJB model, 

list of relationships (where each item in the list is of type different beans can be deployed on different computers 

SabaRelationship) will be defined in the SabaEntityBean transparently. Separation of interfaces from the implemen- 

class. By default (i.e., at SabaEntityBean level), the list will tation enables automated generation of stubs and skeletons 

be defined to be empty. When component developers create 10 that hide the details of network communications. A client 

an entity bean by extending SabaEntityBean, they will be application (or a bean that relies on another bean) 

able to declaratively specify relationships between the bean (Subsequent references to a client application should be 

being created and the other beans in the system. Additional interpreted to be inclusive of beans that rely on other beans) 

relationships may be added to existing beans too when a new uses a naming service to first locate the bean and then 

bean is created. 15 interact with it, thus making no assumptions about location 

In the alternative embodiment, besides lifetime of any given component, 

management, the declared relationships could also be used Naming 

for navigational purposes within the object model. As an As alluded to in the previous paragraph, "before using a 
example, consider a situation where the SabaRegistration bean, it must first be located. All EJB application servers are 
bean is related to the SabaQass bean, which in turn is related 20 required to provide Java Naming and Directory Service 
to the SabaLocation bean. One would like to be able to (JNDI) access for bean users. To use JNDI, a client appli- 
retrieve attributes of the location (say, the map) of the class, cation would typically first get an "initial context" (driven 
given a registration. A new class, SabaCompositeRelation- by properties such as where to find the EJB server, some- 
ship will allow one to compose navigational paths in terms what analogous to the JDBC connect string for locating a 
of basic SabaRelationship objects. Then, given a source 25 database), and then using the context, look up the home 
object and the name (or id) of a composite relationship, the interface of the bean by its name. Using the home interface, 
SabaCompositeRelationship class will be able to fetch the the client can find a specific instance of a bean, create a new 
destination objects). instance, or remove an instance. The naming service would 
Vendor-specific Wrappers be used and the interaction would be the same even if the 
In the alternative embodiment, when some areas within 30 bean instance is present locally (i.e., exists in the same Java 
the J2EE specifications are still not standardized and are left Virtual Machine) instead of being deployed on a remote 
up to individual vendors for implementation, additional machine. 

facilities will be needed. To prevent vendor-specific imple- The JNDI naming mechanism also obviates the need for 

mentation details from migrating into SABA code, the BDK the SabaClassRegistry mechanism that is used at present, 

would provide a class SabaJ2EEvendor that provides a 35 The client application looks for a bean by a name (say, 

wrapper around vendor-specific implementations. Authentication). Any bean class that provides the implemen- 

SabaJ2EEVendor provides static methods that can be used to tation of the remote and home interfaces can be deployed 1 

perform activities in a vendor-neutral fashion in SAB A code. against that name in the application server. Thus, at one 

An example method in SabaJ2EEvendor is installation, the default bean class SabaPlatformLogin can 

getInitialContext( ),which encapsulates the logic for getting 40 be deployed with a name of Authentication, whereas at some 

an initial context (at present, the mechanism for this is other installation, the bean class SabaLDAP Login can be 

vendor-dependent). To use a particular vendor's implemen- deployed with the same external name to use a different 

tation of J2EE specifications, one will have to provide authentication logic, 

implementations of the methods in this class. By default, the Persistence 

BDK will provide implementations of this class for a few 45 One of the benefits of using EJBs is that component 

selected J2EE servers. developers do not have to worry about persistence of data, 

Miscellaneous Classes as the container hosting the (entity) beans can manage such 

In an alternative embodiment, in addition to the persistence. Automatic persistence service provided by the 

foregoing, the BDK also provides the following utility application server enhances the productivity of bean 

classes that can be useful for developing components: 50 developers, is more efficient at runtime, and allows the 

SabaProperties, DateUtil, FormatUtil, LocaleUtil, bean's definition to be independent of the type of data store 

SystemUtil, and Timer. Also, the following exception used for persistence (e.g., a relational database or an object- 

classes are supported: SabaException, oriented database). A component developer will be respon- 

SabaSecurity Exception, Saba Fatal-Exception, sible for declaring part or all of the attributes of an entity 

AttributeNotFoundException, and SabaRelationshipViola- 55 bean as persistent in its deployment descriptor, and then 

tionException. For logging purposes, the BDK provides a mapping them to fields in a database at deployment time. 

SabaLog class and for debugging purposes, the BDK pro- The interface and mechanism of such mapping would 

vides a SabaDebug class. The functionality provided by the depend upon the application server being used, 

foregoing classes is similar to that available currently. The bean is automatically saved to the persistent store 

The use of the various classes and interfaces discussed in 60 when it is created by a client application using the create( ) 

this section is described in the "Application Development method, and when the container decides to synchronize the 

Model" section. bean's state with the database if the bean's data has been 

Services changed by the client application. The container's decision 

A number of services are required by application devel- is based on such factors as transactions, concurrency, and 

opers to develop robust, flexible, and scalable systems. A 65 resource management. The container will remove the data 

number of these services are provided by the commercially from persistent store when the remove( ) method is called by 

available application servers that host the EJB components. a client on an entity bean. 
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Concurrency 

A component developer does not have to worry about 
concurrent access to an entity bean from multiple transac- 
tions (such as from several client applications). It is the 
responsibility of the container hosting the bean to ensure 
synchronization for entity objects. Indeed, use of the key- 
word synchronized is prohibited by the EJB Specification. 
Concurrent access for session beans is not meaningful, since 
by definition an instance of a stateful session bean can be 
used by only one client and stateless session beans do not 
maintain any data that needs to be shared. 

Transactions 

For transactions, an application developer has two 
options: 1) to explicitly demarcate the boundaries of a 
transaction, or 2) to use declarative transactional manage- 
ment available with EJBs. Use of declarative transactional 
management is cleaner and is strongly recommended. In this 
case, the level of granularity for managing transactions 
corresponds to methods in a bean. Instead of interleaving 
transaction boundaries within business logic, transactional 
attributes are separately declared in the bean's deployment 
descriptor (for a specific method, or as the bean's default) as 
one of the following six options: TX_NOT_SUPPORTED, 
TX_SUPPORTS, TX_REQUIRED, TX_REQUIRES_ 
NEW, TX_M AND ATO RY, TX_BEAN_MANAGED. 
Details of these can be found in books on EJB. 

Security 

As discussed earlier, application developers can use a 
stateless session bean, SabaPlatformLogin, to authenticate a 
user. In the deployment descriptor for every bean, access 
control entries are defined which list the identities (users or 
roles) that are allowed to invoke a specific method 
(alternatively, an access control list can act as the default for 
all the methods in a bean). According to EJB Specification, 
each client application accessing an EJB object must have an 
associated java.security. Identity object (generally associ- 
ated at login time). The general Security system used in the 
present invention was discussed in more detail above. 

Read/Write/Arbitrary Privileges 

Search 

To locate an instance of an entity bean, each entity bean 
provides a method findByPrimaryKey( ) in its home inter- 
face. In addition, other finder methods (which must be 
named in accordance with the pattern find<criterion>)can 
also be provided. With container-managed persistence, the 
container generates the implementations of such methods 
automatically at deployment time. The mapping of finder 
methods to the database is vendor-dependent at present, 
though a standardized syntax for the same is a goal of EJB 
2.0 Specification effort In the meantime, a developer can 
implement the finder methods in terms of findUsingRQL( ) 
and findUstngRQLURI( ) methods available in SabaEntity- 
Bean. 

Logging & Debugging 

A component may be used by multiple applications in an 
interleaving fashion. 

An application could have components distributed over 
multiple computers — how to assemble a unified log — use a 
"log server" bean — heavy performance price, impacts 
debugging class too. 

Turning on and off debugging on a component basis. 
Mechanics of how to do it without having runtime checks 
every time a method in Debug is called. What if one app 
wants a component to turn debugging on whereas another 
wants to turn it off. 

Application Development Model 

In the alternative embodiment, to develop an application 
using the BDK, an object model of the application domain 
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should be first developed, retaining a separation between 
objects that represent business processes and those that 
represent business data. The two types of objects, obviously, 
map to session beans and entity beans in EJB parlance. A 

5 controller object, for instance, would indicate a session bean 
whereas an object that persists its data would indicate an 
entity bean. An application would typically also include UI 
components (such as JSP pages or servlets) which would use 
such business components. Thus, there are two primary roles 

10 from an application development standpoint: 

1. component developer, and 

2. component user. 

It is possible that an individual may play both the roles. 
Indeed, a component developer may need to rely on another 
15 component, and thus be a user as well as a developer. We 
will first look at the role of a component developer in the 
next subsection, and then look at the responsibilities of the 
component user. Finally, we will look at how an application 
can be packaged in this alternative embodiment. 
20 Component Developer 

To create a component, a developer needs to perform the 
following steps. 

1. Define the remote interface of the component. 
2j 2. Define the home interface of the component 

3. Define the bean class. 

4. Create the deployment descriptor of the component. 
As an example, one will build a simple SabaPerson 

component SabaPerson is a container- managed entity bean 
30 useful for explaining some basic concepts in EJBs and the 
BDK framework. One then illustrates issues surrounding 
business logic coding, transactions, and persistence in a 
question-answer format. Note that for simplicity's sake, 
package, import, try /catch/finally, etc., statements are not 
35 included in the following code segments. 
The Remote Interface 



public interface SabaPerson extends ISabaRcmote { 
public String getFuUNameQ throws RM I Exception; 
public String getFiretNameO throws RM Exception; 
public String getLastNamefJ throws RMIExccption; 
public void setFirstName(String name) throws 
RMIExccption; 

public void sctLastNnme( String name) throws RMIExccption; 
45 } 



The remote interface provides the business methods or the 
world's view of the component. In our case, we have a single 
method that a client can use to get the person's full name. 
Also recall that ISabaRemote already declares setAttrVal( ) 
and getAtu*Val( ) methods for manipulating the attribute 
values (such as fName and IName declared in the bean 
class), so they don't need to be declared again. 

The Home Interface 



public interface SabaPersonHome extends I Saba Home { 

public SabaPereonEJB flndBy Primary Key(SabaPrimary Key id) 

throws FinderException, RMI Exception; 
public Collection findByName(String fName, String IName) 

throws FinderException, RMIExccption; 
public SabaPersooEJB create (String fName, String IName) 
throws Create Exception, RMIExccption; 
> 

65 

For container-managed beans, the container automatically 
provides an implementation of the findByPrimaryKey( ) 
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method and generates trie code for other finders (such as 
findByName()) from an external description, which pending 
EJB 2.0 Specification, is vendor-specific. 
The Bean Class 



public dass SabaPcrsonEJB extends Sab a Entity Bean { 
public String id; 
public String fName; 
public String IName; 

public String getFullNameO throws RMIException 



{ 
} 

public String getFirstName0 throws RMIException 



return (fName + IName); 



return (String) getAttrVal ("fName"); 



public void setFirstName(String name) throws RMIException . 



setAttrVil(' i £Name" > name); 



20 



public void ejbCreate(String fName, String IName) 



< 



this, id « IDGenerator.getNewtDQ; 
this .fName - fName; 
this J Name - IName; 



} 

public void ejbFo6tCteate(String fName, String IName) 
{ 

// No action needs to be taken. 

} 
} 
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<entity> 

<description> 

This is part of the deployment descriptor of the 
SabaPcrsoa entity 
bean. 

</description> 

<cjb-nflme>SabaPcrson</ejb-namc> 
<home>com.saba.examptes.SabaPersonHome</home> 



40 



The bean class provides implementations for the business 
methods declared in the remote interface. Note that the fields 
in the bean class are declared to be public. The EJB 
Specification require this for container-managed persistent 35 
fields. Furthermore, this is also required by the setAttrVal( ) 
and getAltrVal( ) methods for fields that should be accessible 
via this methods (the methods use reflection to locate the 
fields). The consequences of such visibility are limited, 
however, because the user of a bean only interact with the 
bean through the home and remote interfaces. It is not 
possible for a client to directly assign values to or retrieve 
values from such public fields without going through the 
accessor and mutator methods defined in the remote inter- 
face. 

For each different signature of create( ) method in the 
home interface, corresponding ejbCreate( ) and 
ejbPostCreate( ) methods need to be defined in the bean 
class. The code for the bean class is consistent with this 
requirement. 

The Deployment Descriptor 

In EJB Specification vl.l (which can be found at the 
java.sun.com web site), the deployment descriptor is an 
XML file that declares such things as container-managed 
persistent fields and security and transactional characteris- 
tics of the bean and its methods. The following example 
shows part of a deployment descriptor. 
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-continued 



10 



is 



<remote> . . . </remote> 

<ejb-clas5> . . . <l ejb-class > 

<prim-key-class> . . . <J prim-key-class > 

<pe isistcnce-typoContaine r</persistence-type > 

<cmp-fic!d>id<^cmp-fieJd> 

<cmp- field> fName </cmp-field> 

<cmp- ficld> INamc</cmp-ficl d> 



<container-transaction> 

<method> 

<ejb-namc>SabaPerson</ejb-name> 
<method- name>*</method-name> 

</method> 

<trans-aUributc>Surjported<Vtrans-aUribute> 
</con tainer- transaction > 
</entity> 



In EJB Specification 1.0, the deployment descriptor is a 
text file with a somewhat different format. The deployment 
descriptor is generally created using a GUI tool, generally 
supplied by EJB Server vendors. Additional information on 
deployment descriptors can be obtained from EJB literature 
and tool manuals. 

Depending upon the kind of business logic, there are 
different ways of encoding business logic in EJBs. Of 
course, implementation of the methods declared in the 
remote interface of a session bean or an entity bean encodes 
business logic. In addition, EJB provides "hooks" or call- 
back methods for implementing additional types of business 
logic. We have already seen the ejbCreate( ) and 
ejbPostCreate( ) methods that one can use in a manner 
analogous to insert triggers in a relational database. 
Similarly, the method ejbRemove( ) (implemented with an 
empty body in SabaEntityBean and SabaSessionBean) can 
be overridden to encode logic related to deletion of a bean. 
For example, if we wish to encode the logic that if a person 
is removed, all the class registrations for that person should 
also be removed, we can override the ejbRemove( ) method 
within SabaPerson in the following manner. The 
ejbRemove( ) method is called just prior to actual removal 
of the data from the persistent store. 



45 
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public void ejbRemoveQ 
{ 

/* Locate the home interface (regnHome) for the 
* * SabaRegistration bean (code not shown) 
V 

Collection regns - (Collection) 
regnHomc.findByPereonlD(this.td); 

Iterator iter - rcgnsiteratorO; 
while (iter.hasNext0) { 

Saba Registration EJB registro - 

(SabaRcgistrationEJB) 
iter.ucxtO; 
registrn.removeQ; 

} 
} 

Other callback methods are ejbLoadQ, ejbStoreQ, 
ejbActivateQ, and ejbPassivate(). 



60 



In the alternative embodiment, transactional integrity can 
be maintained as follows. Consider a session bean which, as 
part of its remote interface, has declared a method 
cancelClass( ) that encapsulates the business process of 
65 canceling a class. As part of class cancellation, we also wish 
to, say, remove the registration records of the persons 
registered for the class. The registration information is 
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maintained by SabaRegistration entity beans. Hence, within 
the implementation of cancelClass( ), besides updating some 
attribute of the SabaClass entity bean to indicate 
cancellation, we would also encode logic for finding the 
Saba Registration entity beans corresponding to that class 
and then removing them. However, either all these activities 
must succeed atomically, or no change to persistent store 
should be made (i.e., the activities constitute a transaction). 
This would be accomplished by declaring a transactional 
attribute of TX_JUEQUIRED for the method cancelClass( ) 
in the bean's deployment descriptor. If the calling client or 
bean already has a transaction started, the method will then 
be executed within the scope of that transaction; otherwise, 
a new transaction will automatically be started for this 
method. 
How Can 

In an alternative embodiment, complex data types can be 
persisted for container-managed entity beans as follows. 
Suppose there is an entity bean with an attribute that has an 
array of strings as a data type. Since relational databases do 
not support such a data type, one cannot directly map the 
attribute to some column in a database. However, at save 
time, one can potentially convert the array into a single 
String by concatenating the elements within the array and 
using a marker character to delineate various entries. Then, 
at retrieval time, one can look for the marker character and 
reconstitute the array. Entity beans provide two callback 
methods, ejbStore( ) and ejbLoad( ) that can be used for such 
a purpose. SabaEntityBean by default provides empty 
implementations of such methods. An application developer 
can override these methods within the definition of a bean 
and thus persist complex data types. 

In the alternative embodiment, every class in an applica- 
tion does not have to be a bean. Indeed, with the overhead 
of locating a bean through a naming service and going 
through the home and remote interfaces of a bean to perform 
useful work would negatively impact performance (though 
some servers will optimize the process for beans located 
within the same virtual machine). The application develop- 
ers can implement selected classes as helper classes and not 
as beans. Sun Microsystems' J2EE Application Program- 
ming Model identifies certain instances where helper classes 
are applicable. One such example is dependent classes that 
can only be accessed indirectly through other classes 
(beans). Sun's J2EE APM offers CreditCard and Address 
classes as examples of a dependent classes. 

EJBs are packaged as EJB jar files that are comprised of 
the class files for the bean class, the home interface, the 
remote interface, the primary key class (if applicable), in 
addition to the deployment descriptor and a manifest. The jar 
file can be created using the j ar application supplied with 
JDK, or by using some GUI front-end utility provided by the 
J2EE server being used. The deployment mechanism varies 
with the servers. For Weblogic server, an entry can be made 
in the weblogic.properties file; for Sun's reference 
implementation, the deploytool utility can be used to 
achieve this in an interactive manner. 

At present, the EJB Specification does not provide a 
mechanism for declaring such constraints, and this would 
have to be achieved programmatically in the create( ) and 
mutator method(s) of the entity beans. 

Component User 

As described above, in the alternative embodiment, a 
partial example of usage of a component was described in 
the context of business logic encoding. This section provides 
a fuller picture of how a component is used in an alternative 
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embodiment, by either another bean or a client application. 
The primary steps in both the cases are the same: 

1. locate the home interface of the bean; 

2. using the home interface, create a new instance or find 
one or more existing instances of the bean; and 

3. invoke the bean's methods to accomplish tasks. 

To locate the bean, JNDI is used. There arc some varia- 
tions in how JNDI calls are used with different EJB servers. 
Here we use the getInitialContext( ) method in the 
1 SabaJ2EEVendor class for locating the SabaRegistration 
bean. 



15 Initial Context cm - 

SabaJ2EEVtndor.gptInitialContcartO; 

Object objref - ctx L lookup^ SabaRe gis tratio n 

SabaRcgistrationHome regnHome = (SabaRegjstrationHome) , 

PortableRemoteObjecLnarrow(obj ref, 

SabaRegis tratio aHo me. class); 



Once the home interface of the bean is so located, we can 
use it to create new instances of the bean or find existing 
ones. In an earlier example, we had used the home interface 
for finding instances of a bean. Another example, this time 
25 for creating an instance, is presented below. 

SabaRegistration regstrn=regnHome.create(personID, 
classID); 

Subsequently, we can invoke business methods of the 
bean simply as follows, 

regstrn.setAlu*Val(feePaid, true); 

In addition to the foregoing, additional methods 
(implemented by the bean container) are available for get- 
ting a bean's metadata (from which its primary key class, 

3S remote interface class, etc. can be obtained), comparing two 
beans for identity, etc. Many of these methods are used in 
building tools, such as those for deployment purposes. If 
additional information about these methods is needed, 
please consult the available EJB literature. 

^ Those skilled in these arts will understand that various 
other alternative embodiments of a business application 
server system and related development kit for developers, 
may be designed around these basic concepts without devi- 
ating from the unique features provided by applicants in this 

4S invention. 

Security System 

In a preferred embodiment of the present invention, the 
Platform's BDK 519 provides an extremely powerful model 
for assigning security; that is, defining the sets of allowed 
5Q operations that groups of users can perform. It supports both 
extremely sophisticated definitions of an allowed operation 
and a scalable model for assigning and partitioning security. 
Specifically, the following features are provided: 
Security operations can be specified according to either 
55 the general class of business object or to specific, 
individual business objects. 
Support for both shared security operations (view, update, 
delete, etc) and business-object specific security opera- 
tions. 

60 Security operations can be assigned based on a customi- 
zable partitioning of business objects into domains. 
Security operations can be assigned based on either 
universal or domain-specific user groupings. 
Definitions 

65 The following concepts are central to the Platform's 
Security Model. A Security List Member is any entity that 
can be assigned privileges in the system. Members can be 
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can be individual users of the system (employees or 
customers); they can also be associated with generic roles, 
such as a system administrator, or even an automated 
process, such as an Interconnect ChangeManager. 

A Privilege is a set of one or more possible security 5 
operations. There are several types of privileges as shown 
below in Table 1: 
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that users who have access to a domain can access objects 
in that domain, and that users who have access to ancestors 
of a given domain also have access to objects in that domain. 

Extensions to the basic domain model may include the 
ability to define multiple, independent domain axes. For 
example, one domain hierarchy might be based on 
geography, another on business function. 



TABLE 1 



Category 
Atomic Privilege 



Component Privilege 



Instance Privilege 



Complex Privilege 



Description 

The most fine-grained form 
of privilege. Defines a 
single type of security 
operation. 

An Atomic Privilege 
applies to a specific 
category of , business .object 
An Atomic Privilege 
applied to a specific 
business object 
A grouping of one or more 
privileges 



Example 
Create, Delete 



Create Class, 
View Registrations, 
.Confirorlnteraal Order., 
View the "Monthly 
Cancellations" Report 

Create, modify, and delete 
classes 



The Platform 501 supports several pre-defined atomic privi- 
leges that apply to all business objects. The pre-defined 
atomic privileges are shown below in Table 2. 

TABLE 2 



Privilege Description 

New Create a new instance of this business 

object 

View Mew summary or detail information about 

an existing business object 

Edit Change information about an existing 

business object 

Delete Delete an existing business object 

Change Domain Set the domain of an existing business 
object 



Specific categories of business objects can also define 
additional privileges specific to that category. For example, 
the following component privileges only apply to the "Pur- 
chase Order*' business object: 

Change Expiry Date 

Change Initial Credit 

Change Status 

Change Terms 

Domains are the Platform's 501 partitioning mechanism 
for business objects. Domains allow users to define a hier- 
archical structure that models their organization or business, 
for example, based on geography or division. 
For example, the following simple example shows a three- 
domain organization, with a root "World" domain and two 
child "US" and "Europe" domains. 



World 



I 











us 




Europe 



All business objects are assigned a specific domain and 
belong to that domain. In turn, security privileges are 
assigned on specific domains. The domain hierarchy is 
automatically enforced during security checks. This means 



25 Security Lists are the mechanism by which members are 
matched with privileges. A Security List defines a set of 
domain-specific privileges and a set of list members. Secu- 
rity Lists are created in a two-step process as follows: 

First, a set of privileges are added to a security list, where 
30 each privilege is applied to a specific domain. A privi- 
lege within a sec urity lis t — that is, a privilege applied 
to a specific domain — is known as a "granted pri vi- 
■ lege," < 

35 Second^s eLof members are_addedJo a. security list. 
Privileges are calculated at runtime based on all the 
security lists a user belongs to. At least one of the lists must 
contain a required privilege in the appropriate domain. This 
combined use of privileges and security lists supports two 

40 paradigms for administering security across domains: 

1. A centralized approach wherein global administrators 
define security lists that contain a set of (privilege, 
object, domain) triples, that is, one security list can 
apply across different domains. The same global 

45 administrators assign members to security lists. 

2. A decentralized approach wherein global administrators 
define complex privileges that contain a set of 
(privilege, object) pairs with no domain information. 
These serve as "security roles", effectively, global 

50 security lists that are domains-independent. Adminis- 
trators for individual domains then define domain- 
specific security lists containing these privileges. The 
domain administrators assign members in their domain 
to security lists. 
55 The following example shows how privileges work in 
practice. T\vo security lists are shown below in Table 3 and 
Table 4 containing the following granted privileges: 



65 



TABLE 3 




"Customer" Security List 




Privilege 


Business Object Category 


Domain 


View 


Class 


World 


Create 


Order 


US 
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"US Instructor" Security List 








Privilege Business Object Category 


Domain 


View Class 


World 


Create Class 


US 


Delete Class 


US 


Create Conference Room 


us 


View Conference Room 


World 


Schedule Projector 


US 


For purposes of this example, also assume that the instances 


of business objects shown below in Table 5 exist: 


TABLES 




Business Object Category ' Business Object 


Domain 


Cass English 101 


US 


Class Spanish 101 


Europe 


Conference Room Purple Room 


World 


Conference Room Lavender Room 


US 


Projector Projector 1520 


Europe 


Projector Projector 1120 


US 



10 



20 



If Userl only belongs to "Customer" security list, Userl can 
perform the following operations: 

View Class "English 101" 

View Class "Spanish 101" 

Create a new Order for Class "English 101" 
However, User 1 is not permitted to perform the following 
operations: 

Order the class "Spanish 101" to be taken in Europe 
[because this would require a Order with a domain of 
"Europe"] 

Mew the Purple Room 

Mew the Lavender Room 
If User2 belongs to both the "Customer" and "US Instruc- 
tor" security lists, then User2 can peform the following 
operations: 

Mew Class "English 101" 

Create a class "English 101" in the "US" domain 

Mew the Lavender Room 

Mew the Purple Room 

Schedule Projector 1120 
However, User2 is not permitted to perform the following 
operations: 

Create a new Order for Class "Spanish 101" to be taken 
in Europe 

Create a class "French 101" in the "Europe" domain 
Schedule Projector 1520 

Hie Persistence Layer of the BDK 519 automatically 
takes account of the predefined atomic privileges (new, 
view, etc) in its behavior. Thus, search results using standard 
finders will only return objects for which a user has view 
privileges, and update operations for which a user does not 
have privileges will automatically throw a Security excep- 
tion. In addition, the BDK 519 provides the ability to 
explicitly query the security model using the API described 
below. 

Security System API 

The BDK 519 provides a Java-based API for managing 
security. As described in the BDK section, this API uses an 
EJB-style session manager named "SabaSessionManager" 
and a set of helper classes. 



25 



1. A set of interfaces representing the basic concepts in the security model. 

// [Privilege - The base class of privilege. A Privilege is 

anything that can be added to a Security List 

public interface [Privilege; 

// IAtomicPrivilegc - A single allowable operation 

public interface LAtomicPrivilege extends {Privilege; 

// ICcmponentPrivilege - A single allowable operation on a specific 

object class. 

public interface IComponentPrivilege extends IAtomicPrivilege; 
// [InstanccPrivilege - A single allowable operation on a specific 
object instance. 

public interface IlnstancePrivilege extends IComponentPrivilege; 
// IComplcxPrivilcgc - A structured privilege, capable of grouping 
other 

atomic or .complex privileges. ... 
public interface ICbmplexPrivilege extends [Privilege, [Handle; 
// Domain - A business object representing an entry in the Domain 
hierarchy 

public interface Domain extends [Handle; 

// ISecurityListMember is any interface that can be a member of a 
security list, including [Role, [Party ([Person or [Organization), 
or [Group 

public interface [ Security ListMcmbcr extends [Handle; 

// ISecuritylist matches granted privileges to a set of members 

public interface [Security List extends (Handle; 



2. Aset of concrete classes capturing the available privileges 
in the system. These classes are application-dependent; 
i.e. there are one set of classes associated with the 
Learning application built on Platform, another set asso- 
ciated with the Performance application, etc. 



For example: 



45 



50 



55 



60 



65 



public class Instance Privileges implements 
IlnstancePrivilege { 

/* Define the set of common atomic privileges that 

apply to all objects in the system. */ 

public static final int kEdit - 2; 

public static final int kDelete - 3; 

public static final int kView - 6; 

} 

public class ComponentPrivileges implements 

IComponentPrivilege { 

/* Define the set of common atomic privileges that 
apply to all components in the system. Notice that 
this class includes all atomic privileges that apply 
to instances */ 

public static final int kNew - 1; 
public static final int kEdit - 2; 
public static final int kDelete - 3; 
public static final int kView - 6; 

public class PurchaseOrdcr Privileges extends ComponentPrivileges 

// Privileges specific to the Purchase Order business 
object 

public static final int kChangeDomain - 7; 
public static final int kChangeStatus - 11; 
public static final int kChangeTerms -12; 
public static final int kChangelnittalCredit - 13; 
public static final int kChange Expiry Date - 14; 
public static final int kChangeCurrency - 15; 

} 
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2. The interface of toe manager used to create and manage 

security lists. continued 



public interface SabaSccurity Manager extends ISabaRcmotc { 
/* methods for creating and updating security lists */ 
public ISecurityList createSecurityList (SecurityDetail detail); 
public SecurityDctail getDetail (ISecurityList thcSecurityUst); 
public void updateflSecurityList theSecurityList, 

SecurityDctail detail); 

public void remove(ISecurityList theSecurityList); 

/• methods for adding & removing privileges to security lists 

V 

public void addPrivilege(ISecurityList thelist, IPrivilege 
thePrivilege, Domain theDomain); 

public void removePrivilege(I Security List theList, IPrivilege 
thePrivilege, Domain theDomain); 

f* methods for adding & removing members from security lists */ 

public void addMember(ISecurityList theList, 
ISecurityListMember theMember); 

public void removcMembcr (ISecurityList theList, 
ISecurityListMember theMember); 

/* methods to check privileges */ 

public boolean isMcmber(ISecurityList theList, 
ISecurityListMember theMember); 

public boolean hasPrivilege (ISecurityListMember theMember, 
IAtomicPrivilege thePrivilege, Domain theDomain); 

public Collection getPrivileges (ISecurityListMember theMember, 
I Component theComponent, Domain theDomain); 
/* standard finder V 

public ISecurityList findSecuritylistByKey(String id); 

public Collection nndSecuritylis£ByName(String name); 

public Collection findAl ISecurity Lists 0; 
} /• SabaSecurityManager */ 



The following code fragment demonstrates how the Security 
API can be used to create a new security list, assign users to 
that security list, and check privileges for that user. Note that 
this code example uses several other session bean managers, 
such as a DomainManager and PartyManager, provided as 
part of Platform. 
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/* Step 4: check a user's privileges V 

IPrivilege ectitQassPriv - (IPrivilege) new 

Conn;onentPrivileges(CfernpoaemPrivUeges.kEdit, 
classesCo mponent); 

boolean canEditOasses - 
theSecurityManager.hasPrivilege(member, 
editOassPriv, domain); 



1S Best Mode 

.. » In. a. preferred embodiment, the Platform's BDK security 
API focuses on the database structures and SQL used to 

20 store and query security information. It also touches on the 
algorithms used in implementing the Java API. 



Information related to security is stored database tables as 
shown below. The Platform's BDK Security System uses 
Java code to read and write values to these database tables. 

fgt_domain stores all domains as shown below in Table 6. 
TABLE 6 



Column Name 


type 


Required? 


Description 


id 


OBJECTID 


y 




description 


varchar (255) 


n 


Long descriptive string 


35 






for the domain. 


name 


varchar (25) 


y 


Name of the domain 


Parent Id 


OBJECTID 


N 


ID of the parent domain 



/ m Step 1: create a security list V 40 

String privName - "Guest"; 

String privDescription «• "Guest login and access"; 

Domain domain » 

theDomainManager.findDomainByKey 
("dominOOOOOOOOOOOlOOO"); 

String domain ID «■ domaiagetldQ; 45 
Security Detail theDetail - 

new Security Detail(privName, privDescription, 
domain ID); 

IsecurityList securityLut - 

theScairityMa nager.creatc Security List (thcDe tail); 
I* Step 2: grant privileges by adding them to the list */ 5Q 
IComponent classes Component - 

theCompooentMaiiager.getCompoiient ("classes"); 
/* create atomic privileges and add them */ 
IPrivilege viewClasses - (IPrivilege) 

new CtomponentPrivilegcstCjomponeQtPrivilcgcsJiVicw, 
classesComponent); 

theSecurityManager.addPrivilege(seciirityList, 
viewClasses, domain); 

IComponent groupCo mponent - 

theComponentManager.getComponcnt( M Product Group"); 
IPrivilege viewGroups - (IPrivilege) 

new componentPrivileges(ComponentPriviIeges^View; 
classesComponent); 

theSecurityManager.adaTrivUege(securityList, viewGroups, 

domain); 

/* Step 3: assign a member to the security list •/ 
ISecurityListMember member - (ISecurityListMember) 
thcPartyManagcr.findEmployccByKcy 
("emplofJOOOOOOOOOOlOOO"); 65 
tbeSecuhtyManager.8ddMember(SecurityList, member); 



fgt__ss_privs stores all atomic privileges as shown below in 
Table 7a. 

TABLE 7a 



Column Name type 



Required? Description 



id OBJECTID 
object_typc OBJECTID 

priv_name varchar (80) 



y 

Y 



pnv_seq 



INT 



55 



60 



object Id (data dictionary 
class id) to which the 
privilege applies, 
a description string for 
the privilege, 
a number which 
identifies the 
type of privilege. 

1 -> New 

2 -> Edit 

3 -> Delete 

4 -> Save 
etc. 

Note: 1-5 common to all 
classes 11 onwards - 
class specific. 



For example, in Table 7b below, the following data captures 
the available privileges for the Purchase Order business 
object. Notice that the values in the priv_seq column 
directly correspond to the constants defined by PurchaseOr- 
derPrivileges class defined in the Java API. 
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TABLE 7b 



id 


objcct_typc 


priv_name 


priv_seq 


ssprvO00O00000001008 


pyc&t000000000001036 


New 


1 


Ksprv000000000002D08 


pycatOOO OOOOOOOOl 036 


Edit 


2 


ssprv000000000003009 


pycat000000000001036 


Delete 


3 


sspv000000000010175 


pycat0000O00O0001036 


View 


6 


ssprvOOOOOOOOOO 10224 


pycat0O0CO00O0001036 


Change Domain 


7 


ssprv000000000007120 


pycat000000000001036 


Change Status 


13 


asprv000000000007121 


pycat000000000001036 


Change Terms 


12 


ssprv000000000007122 


pycatOOO OOOOOOOOl 036 


Change Initial Credit 


13 


ssprv000000000007123 


pycatOOO 00000 0001 036 


Change Expiry Date 


14 



15 



fgt_list stores all security lists as shown below in Table 8a. 



TABLE 8a 



Column Name 


type 


Required? 


Description 


id 


OBJECTED 


Y 




description 


varchar (255) 


N 


Description of this list 


name 


varchar (25) 


Y 


Name of the list 


owner_id 


OBJECTED 


N 


The owning object 








of this list if any 


security 


BOOLEAN 


Y 


0 - Not a security list, 








1 = Security List 
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id 



name description 



security 



lis taOO 000000 0002003 User A generic law-privileged user 



Column Name Type 



For example, in Table 8b below, the following data defines 
a security list to capture generic user privilges: 

TABLE 8b 



Rq? Description 



id OBJECTTD 
granted_on_id OBJECTTD 



25 



granted_to_id OBJECTED 

privs varchar (50) 

domain_id OBJECTTD 



30 



y 50 character bitmap containing 

the granted privileges. 
N Foreign key to the domain on 

which this privilege is granted. 



Foreign key to the business 
object class or instance on 
which this privilege is granted. 
Foreign key to the security list 
on which this privilege is 



Notice that this schema shown in Table 10 stores all atomic 
privileges on a (object, domain, list) triple in a single row by 
appending the integer keys of the atomic privilges into a 
single string. Notice also that the schema shown in Table 10 
can capture both: 



40 



fgt_list_entry stores all members of a security list as shown 
below in Table 9. 

TABLE 9 



Column Name type 



Rq? Description 



id 

list id 

person id 



OBJECTED 
OBJECTED 
OBJECTED 



Foreign key to a security list 
Foreign key to a list member 
The object ED may be a 
person, role, or group. 
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fgt_ss_grants stores all granted privileges as shown below 
in Table 10. 



1) privileges on business object classes, by storing the 
data dictionary primary key of the class in the granted_ 
on_id column. 

2) privileges on business object instances, by storing the 
object id of the instance in the granted_on_Jd column. 

For example, the following row from Table 10 describes a 
grant that allows members of the "Users" security list to 
create and view orders, but not edit or delete them. The 
"ddcls" prefix (for "data dictionary class") on the granted_ 
on_id value indicates that this OBJECTID refers to a 
business object class. The I st and 6* bits of the privs flag are 
on, providing create and view privileges only. 



id grantcd_on id 


grantcd__to_id 


6sgrn000000000001264 ddclsU00000000001055 


lista0O000O000002003 


privs 


domain id 


lOOOOlOOOOOOOOOOOOOOOro 


dominOOOOOOOOOOOXOl 
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The following row from Table 10 describes a grant that 

allows the same list to execute a specific report. The "reprt" -continued 

(for "report") prefix on the granted_on_jd value indicates ^ 

that this OBJECT1D refers to a specific instance of the 1 1 to_chftr(decode(sum(to_numbcr(substr(s.privs > 5, i))),o,o,i)) 

Report business Object. The 11 rt bit of the privs flag is on, It to_char(decode(sum(to_numbcr(substr(s.priv8, 6, 1))),0A3)) 

meaning the grant gives Execute privileges only. 



id granted on Ld 


grant ed_to_id 


ssgrn000000000202056 reprtOOOOOOOOOOOlOOO 


lista000000000002003 


privs 


domain_id 


0000000000 100000(X30000000(X)00000000000000(X^ 


dominOOOOOOOOOOOOOOl 



The Platform's BDK Security" System also utilizes an 
addPrivilege( ) method. The addprivilege( ) method has 
different logic depending on whether a row already exists in 20 
fgt_ss_grants for the combination of security list, business 
object, and domain. If a row exists, it retrieves the existing 
row, sets the additional bits defined by the I Privilege 
parameter, then updates the row. If no row exists, it creates 
a empty privilege bitmap, sets the bits defined by the 25 
IPrivilege parameter, then inserts a row. 

The Platform's BDK Security System also utilizes an 
hasPrivilege( ) method. The addprivilege( ) method executes 
a SQL query to return all privilege bitmaps for each security 
list the user belongs to that match the target object and 
domain parameters. It iterates through each bitmap and 30 
returns true if the privilege has been set in any one. The SQL 
query that is executed is: 



-continued 
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r select all of a user's grants on an class in a given domain, 
parameter 1 * person id 
parameter 2 - class id 
parameter 3 - domain id */ 

select g.id, g.privs from fgt_ss_grants g, fgt_list 1, 

fgt Jist_entry e where e.person_Jd - @@001 and e.list_id - Lid 

and 1 .security = 1 and 

g.granted_to_id - lid and g. granied_o n id o @@002 and 

g.domain_id - 



The BDK Persistence layer also contains code that directly 
accesses these database tables to check security privileges. 45 
A utility class, SabaPrivileges, contains a hasprivso method 
that is called at predefined points by the SabaObject and 
SabaEntityBcao implementations, including whenever 
objects are saved and restored. This method has the follow- 
ing signature: 5Q 
public boolean hasPrivs(String objectID, String classID, 
String domainID, int privToCheck, boolean anydomain) 
SabaPrivileges contains a Java hashtable that caches 
privilege for each business object in the system. The 
hasPrivs( ) method iterates through these privileges to look 
for a match, using logic similar to the 
SabaSecurityManager.hasPrivilege( ) method. 

If the cache is empty, SabaPrivileges queries the database 
to load the appropriate privileges. The SQL used is the 
following: 

60 



select s.grantcd_on_id granted_on, substr( 

to_char(decode(sum(to_numbei (subs tr(s. privs, 1, 1))),0,0,1)) 
to_char(decode(sum(to_aumber(substr(8.privs t 2, 1))),0,Q,1)) 
to_char(dccodcC5um(to_jmmbcr(substr(s.privs ( 3, 1))),0,0,1)) 6 * 
i to_chai(decode(sum(to__number(substr(s.privs, 4, 1))),0,0,1)) 



to_char(decode(sum(to_number(substr(s.privs, 7, 1))),0,0,1)) 
to_chaT(decode(sum(to_nomber(substr(s.privs, 8, 1))),0,0,1)) 
to_char(decodc(sum(to^mnbcrCst:bstr(s.privs, 9, 1))),0,0,1)) 
to_clar(decode(sum(to_number(substr(s.privs > 10, 1))),0,0,1)) 
to_char(decode(sum(to _nmnber(substr(s,privs, 11, 1))),0,0,1)) 
to_char(decode(sum(to_number(sub5tr(5.privs, 12, 1))),0,0,1)) 
to_char(decode(sum(to_number(stibstr(s.privs, 13, 1))),0,0,1)) 

to char(decode(sum(to_number(substr(s.privs, 14, 1))),0,0,1)) 

to_char(dccodeCsum(to_numbcr(substr(s.privs, 15, 1))),0,0,1)) 
to_cbar(de^e(siim(to^timberCsubsti(s,privs, 16, 1))),0,0,1)) 
to_char(decode(sum(to__number(substr(s.privs, 17, 1))),0,0,1)) 

to char (dccode(sum(to_numbcr(substr(s. privs, 18, 1))),0,0,1)) 

to_char(decode(sum(to_number(substr(s.privs, 19, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s,priv8, 20, 1))),0,0,1)) 
to_char(decc4e(siim(to_number(substr(s.privs, 21, 1))),0,0,1)) 
to_char(deKxle(siim(to_^umberCsubstr(s.privs > 22, 1))),0,0,1)) 
to_chaT(decode(sum(to_number(substr(s.priv5, 23, 1))),0,0,1)) 
to_chaT(decode(sum(to_numberCsubstr(s.priv8, 24, 1))),0,0,1)) 
to_char(decode(sxim(to_numberCsubstr(s,privs. 25, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.privs, 26, 1))),0,0,1)) 
to_char(decode(sum(to_numberCsubstr(s.privs > 27, 1))),0,0,1)) 
to_char(dccodc(sum(to_numberC5ubstr(s.priv5, 28, 1))),0,0,1)) 
to_char(decode(sum(to_nnmber(substr(s.privs, 29, 1))),0,0,1)) 

to char (decode(sum(to_nmnber(substr(s. privs, 30, 1))),0,0,1)) 

to_char(dccodc(sum(to_numbeTCsubstr(s.privs, 31, 1))),0,0,1)) 
to_char(decode(sum(to_nnmber(substr(s.privs, 32, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(6.privs, 33, l)fl,0,0,l)) 

to char(decode(sum(to numbcr(5ubstr(s.privs, 34, 1))),0,0,1)) 

to_char(decode(sum(to_numberCsubstr(s.privs, 35, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(6.priv8, 36, 1))),0,0,1)) 
to_char(dccode(sum(to_numbcrCsubstr(s.privs, 37, 1))),0,0,1)) 
to_char(decode(sum(to_number(substj(s.privs, 38, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(B.privs, 39, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.privs, 40, 1))),0,0,1)) 
to_char(decode(sum(to_nuinberCsubslr(s.privs, 41, 1))),0,0,J)) 
to_char(decode(sum(to_number(substr(6. privs, 42, 1))),0,0,1)) 
to_char(dccode(sum(to_numbcrCsubstr(5.privs, 43, 1))),0,0,1)) 
to_char(decode(sum(to^umbcrCsubstr(8.privs, 44, 1))),0,0,1)) 
to_char(decode(saim(to_number(substr(s.priv«, 45, 1))) ,0,0,1)) 
to_char(dccode(sum(to_jaumbcrCsubstr(5.priv3, 46, 1))),0,0,1)) 
to_char(decode(suin(to_numberCsubstr(8.privs, 47, 1))) ,0,0,1)) 
to_char(decode(sum(to_number(substr(8.priv8, 48, 1))),0,0,1)) 
to_char(decode(sum(to_numbcr(substr(5.priva, 49, 1))),0,0,1)) 
| to_char(deaxleCsuin(to_nuinberCsubstr(s. privs, 50, 1))) ,0,0,1)), 
1, 50) privs, Lnode_id domain_jd from fgt_jss_grants s, 

fgt__list_entry 1, tpt_dummy_flat_tree t where 1. person id - @001 

and 8.granted_j3n_id - @003 and Mist id - s.granied_to_id and 
s.domain_id - trelated_to and (l.group_Jabel is mill or 
Lgroup_label - @002) group by a.granted_on_id, t.node_id 



The SQL used in this query has two unique features: 
It uses a table called tpt_dummy_flat_tree that stores the 

parent/child relationships for all domains in the system. 

This allows it to include a join that obtains privileges 

for both the specified domain and all its parents. 
It checks the value of the privs field bit by bit, and 

concatenates the results together to form a new bitmap 
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that is the union of the bitmap fields for the specified 

domain and all its ancestors. 
The following example data in tpt_dummy_flat_tree 
shown in Table 11 defines the relationships between three 
domains, where dominOOOOOOOOOOOOOOl is the top-level 
parent, dominOOOOOOOOOOOlOOO is its child, and 
dominOOOOOOOOOOOlOOl is its grandchild. 

TABLE 11 



NODE_E> RELATED_TO R REL_ LEVEL 

dominOOOOOOOOOOOOOOl dominOOOOOOCXXXXXWOl I 1 

dominOOOOOOOOOOOlOOO dominOOOOOOOOOOOOOOl A 2 

dominOOOOOOOOOOOlOOO dominOOOOOOOOOOOlOOO I 1 

dominOOOOOOOOOOOlOOl dominOOOOOOOOOOOOOOl A 3 

dominOOOOOOOOOOOlOOl dominOOOOOOOOOOOlOOO A 2 

dominOOOOOOOOOOOlOOl dominOOOOOOOOOOOlOOl I 1 



WDK Server 

The Web Content Server 800 enables the present inven- 
tion to interact with users regardless of the users hardware 
platforms, locations, and software systems. The Web Con- 
tent Server 800 allows the present invention to overcome the 
difficulties of prior art systems associated with having an 
infrastructure which is tightly coupled to application 
products, specific hardware platforms and specific Operating 
systems and related services. 

The Web Content Server 800 can allow the present 
invention to interface with many other industry standard 
software programs to make the exchange and flow of data 
easy and accurate, and enables interconnection with external 
systems, special networks, like SabaNet, and the Internet. 

The Web Content Server 800 is web-enabled and provides 
a unified set of interfaces for interacting with web based 
users as well as other users. 

The Web Content Server 800 can also allow vendors/ 
developers to develop applications on the Platform, make 
use of core technology for information matching and 
distribution, and provide standardized access to connectivity 
with other systems and platforms in a users network. 

As shown in FIG. 8A, one embodiment of an Web 
Content Server 800 provides an interface between users 802, 
804, and 806 and the Platform. The Web Content Server 800 
preferably includes an engine 808, style sheet control system 
810 for various user display protocols, a JAVA Virtual 
Machine 812 and the related runtime support. 

The Style Sheet Control System 810 contains mecha- 
nisms to manipulate various kinds of display style sheets, to 
generate and execute web links, to manage dynamic content 
generation and dynamic generation of Javascript. The Style 
Sheet Control System 810 also can allow vendors/ 
developers to modify, add, or delete the mechanisms in the 
Style Sheet Control System 810. Thus, vendors/developers 
can customize the presentation of data to the users. 
User Generation of Web Content 

Web Content Server 800 can also provide the platform's 
web content generation engine for use by users to create, 
render, and present web content while improving the 
dynamic acquisition of data from a variety of sources 
followed by its reformatting and display via style sheets. 
Using web standards for XML and XSL, Web Content 
Server 800 provides a user with a customizable framework 
for decoupling data from presentation, and generating web 
content in a variety of formats, from standard HTML to 
WML. 

The Web Content Server 800 provides a "page engine" 
808 which allows users (such as developers, c onsultants and 
c ustomers ) to build web content using a separauorrbetween 
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Model, Widget, and View instructions. The engine 808 
separates data production, interaction elements and display 
information, and maintains these aspect of page production 
in different files. 
5 The engine 808 supports three components: (a) Widgets, 
which are reusable interactive components such as buttons 
and data entry fields; (b) Models, which encompass the data 
and user operations used by the application (Data can be 
simple Strings or complex objects); and (c) Views, which 
10 use style sheets to define and control the presentation of 
output to the user. 

Using the system 808 provides, among other things, the 
following advantages for a user: 
Improve maintainability of web content. 
15 Partition web content development between users (such as 
component developers, Java developers, and UI 
developers). 

Provide easy and extensive customizability by users. 

20 Improve productivity of building web content. 

Provide improved authoring and debugging support 
Provide the infrastructure for targeting alternate deploy- 
ment platforms (ie palmtops). 
In one embodiment, the engine 808 uses XML, XSLT 

25 (extensible Stylesheet Language Transformations), and RDF 
(Resource Description Framework), built round a publishing 
framework called Cocoon to enable the functionality of Web 
Content Server 800. 
^W^The engine 808, in conjunction with a set of tools, 

30T utilities, APIs, and predefined widgets and views, acts as a 
platform and provides the user with a set of tools, tag and 
widget libraries, Java classes, and XSL style sheets. Tools 
included with the platform 808 help users perform the 
following activities: (a) A uthoring-^users need to creat e and 

35 maintain cpntrolJ i1r.s,-rriodel files, jwjdget files, and view 
filesQ6]TDebugging — the process starting with obtaining 
data and ending with viewing is involved so having tools or 
methods for debugging problems is essential; and (c) 
Customization — customizing the final product can certainly 

40 be accomplished with the tools used for authoring and 
debugging, but additional tools can radically simplify tasks 
like product upgrades or performing simple customizarions. 

The platform 808 allows content, logic and style to be 
separated out into different XML files, and uses XSL trans- 

45 formation capabilities to merge them resulting in the auto- 
matic creation of HTML through the processing of statically 
or dynamically generated XML files. The platform 808 can 
also generate other, non-HTML based forms of XML 
content, such as XSL:FO rendering to PDF files, client- 

50 dependent transformations such as WML-formatting for 
WAP-enabled devices, or direct XML serving to XML and 
XSL aware clients. 

The platform 808 divides the development of web content 
into three separate levels: (a) XML creation — The XML file 

55 is created by the content ' owners . They do not require 
specific knowledge on^tiow the XML content is further 
processed — they only need to know about the particular 
choser i^DTD" or ta g set for theu istag cin the pr ocess. This 
layer can be performed by users directly, through normal 

60 editors or XML-awar e tools/editor s; (b) XML processing — 
The requested XML file is processed and the logic contained 
in its logicsheet is applied. Unlike other dynamic content 
generators, the logic is separated from the content file; and 
(c) XSL rendering — The created document is then rendered 

65 by applying an XSL stylesheet to it and formatting it to the 
specified resource type (HTML, PDF, XML, WML, 
XHTML, etc.). 
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Dynamic Web Content Development Using Web Content 
Server 800 

The Web Content Server 800 can be based on XML, 
XSLT and Java technologies. Using these technologies, the 
Web Content Server 800 allows for easier user interface 
customization, more flexibility in page functionality, easier 
page maintenance and the creation of more easily reusable 
code. It encourages the separation of data production, inter- 
action elements and display information by separating dif- 
ferent aspect of page production in different files. 

Using platform 808, developing a web page (web content) 
requires the development of the following components: (a) 
a control file; (b) a model file; (c) a view file; and (d) 
Command Managers and Commands. 

The Model contains all the data and interactivity for a 
given page. Users are responsible for generating an XML 
page containing the raw data they wish to display, indepen- 
dent of the appearance of that data or any additional pre- 
sentation information. 

The Model can be implemented using a dynamic page 
engine (JSPs or XSPs). In addition, API 808 provides a 
variety of helper tagsets to automate common scripting 
operations, minimizing the amount of custom scripting 
required by a user. 

Model Developers are typically Java programmers, since 
the bulk of development effort is implementing a companion 
Java Bean that invokes the appropriate SABA Manager API. 
They then use the dynamic features of the engine (tag 
libraries and Java scripts) to place data from the bean onto 
the page. 

The View contains all style and presentation for a given 
page. Users are responsible for implementing an XSLT 
stylesheet that transforms the model into a specific presen- 
tation environment. View developers are typically UI 
designers, since the bulk of authoring effort is crafting the 
HTML for a static page, then adding in the set of XSLT tags 
to create a stylesheet for the associated model page. 

Widgets are a set of predefined UI components and 
presentation elements common to web applications. Widgets 
can have user interactivity (fields, links) or be presentation 
only (images). Widgets can be implemented as XSLT 
stylesheets. The platform 808 includes a predefined set of 
common widgets that can be used by both model and view 
developers. Note also that developers have the option of 
overriding the default widgets to provide enhanced or cus- 
tom functionality if required. 

The important distinction between tag libraries and wid- 
gets is that tag libraries are used in the model and are an aid 
to dynamic content generation, whereas widgets are used in 
the transform step and are an aid to end-content generation. 
Tag libraries can be implemented in Java, whereas widgets 
are preferably implemented as stylesheets. 

FIG. 8B shows bow the engine 808 processes/uses these 
files to produce dynamic web content. 

The process of creating the HTML to send to the browser 
begins with reading the control file, 860. The control file 862 
is simply a file that identifies the model file 864, the view file 
866 and the widget library 868 to use to produce the final 
HTML result 870. The control file 862 also contains link 
transformation information that is used to transform links 
used in the model file 864. This link transformation is used 
to map model-file hyperlink references contained in the 
model file 864 to appropriate control file names. 

The model file 864 is loaded and preprocessed based on 
the information contained in the control file 862. The 
preprocessed model file is executed in three steps. In 872, 
any tags from the tag library are processed. The tag library 
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includes tags for internationalization, command invocation 
and widget management. In 874, the resulting XML file is 
then further processed to generate a Java class. In 876, the 
Java class is executed to produce the model instance 878. 

5 The model instance 878 contains all data and other infor- 
mation needed for display. For example, the model instance 
878 will contain the XML form of the data retrieved by the 
Commands invoked in the model page and it will contain all 
internationalized labels and widgets. In 880, the model 

1Q instance 878 is first transformed using the widget library 
868. In 882, the result of the widget transformation is then 
further transformed using the view transformation file 866 to 
produce the final result 870. 

The process outlined above also highlights how the dif- 
ferent aspects of developing dynamic web content are sepa- 

15 rated. The design of a particular web page is the result of 
answering the following questions: (a) What do I do with 
parameters sent from the browser and what data is needed to 
display the page? How do I perform these tasks? (b) How 
will the user interact with the page? What buttons, entry 

20 fields etc. will the user have? and (c) How are the data and 
the interaction elements displayed on the page? 

The answer to question (a) results in the model page and 
the Command objects used by the model page. The model 
page invokes all needed Commands to perform the tasks of 

25 the page and to produce the data needed for display. The 
answer to question (b) produces a listing of all widgets and 
their linkages to the data being displayed. Although this list 
is part of the model page, the list of widgets and their 
linkages are all declared in a clearly identifiable part of the 

30 page. Finally, the answer to question (c) produces the view 
transformation page. 
Page Development Process 

Typically the page development process starts with an 
HTML mockup of the page. The Web Content Server 800 

35 development process can start with the HTML mockup as 
well. However, users do not modify this mockup to include 
code. Instead the process illustrated in FIG. 8C is followed. 

As illustrated in FIG. 8C, using the HTML mockup 884, 
the user develops three specifications. The data model 

40 specification 886 is developed to meet three basic criteria. 
First, the data model needs to contain enough information to 
drive the interface. For example, if the interface needs to 
display the name of an object, then the data model must 
contain the object name in some form. Second, the data 

45 model specification should maximize reuse of command 
objects. For example, if a command object already exists 
that can retrieve a needed object in a serialized XML format, 
then the data model of the command object should be reused 
instead of reinventing a new XML representation of the 

50 same object. Finally, the data model specification should be 
generic so other pages can reuse the model generation 
components (Commands). How general the data model 
should be is determined by balancing the trade-off between 
performance (since producing more data may incur perfor- 

55 ma nee penalty) and reusability. If producing a more general 
data model causes high performance penalty, then a less 
general solution may be better. On the other hand, if adding 
a few not needed items comes at no or little performance 
cost, then the more general data model is preferred. For 

60 example, objects implementing the IXMLObject interface 
will typically provide more than enough information about 
themselves. The data model specification 886 should essen- 
tially be a sample of the data returned by the Command 
objects and the specification XML should be wrapped in 

65 tags. 

The widget specification 888 is a list of widgets needed by 
the page. These widgets include input fields of all types 
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(textboxes, radio button collections, check box collections, 
dropdown lists, hyperlink buttons, etc.). Besides declaring 
what widgets tbe page needs, the specification 888 can also 
include how these widgets relate to the data model. For 
example, the page may require an edit button widget for 5 
every object it displays. The widget specification 888 can 
therefore indicate that the edit button is "attached to" those 
objects. The widget specification 888 can be very 
incomplete, because users (such as view developers) will 
typically only need the name of the widget for layout 10 
purposes. The widget library will take care of rendering the 
widget itself. 

The third specification is the specification of internation- 
alized items 890 (labels, graphics). The specification 890 
includes a list of all labels and images used on the page. The 15 
specification 890 contains just the name of the label and 
some sample text for the label. 

Once the specifications 886, 888, and 890 are complete, 
the user or a tool, produces a sample model instance 892. 
The user can use the model instance 892 to test the view 20 
stylesheet (by using any standard XSLT tool). The user 
develops the view stylesheet by converting the original 
HTML mockup to an XSLT stylesheet to retrieve dynamic 
data, widgets and internationalized labels from the model 
instance. This conversion process can mostly be done in an 25 
HTML editor. 

Custom izing/Modify in g a Page 

One of the benefits of using the platform 808 for page 
development is in the ease of page customization and page 
modification. Often the look and feel of pages needs to be 30 
modified after the initial design. Using conventional systems 
this process was very painful: individual pages had to be 
revisited by software engineers and tweaked to confirm to 
the new requirements. These new requirements often meant 
changed look of textual/graphical information (e.g., justifi- 35 
cation of text, font, color), changing the layout (e.g., adding 
another Save button to the bottom of the page, moving 
buttons and table columns around), or adding/removing 
information content (e.g., display the price of an offering but 
don't display the description of the offering). Also, often 40 
changes are required across pages: e.g., we want every link 
button to use "Helvetica" instead of "Verdana" for its label, 
and the alt label for the link image should be the same as the 
label of tbe link itself. Sometimes page changes include 
adding new interaction components, e.g. adding a "Cancel** 45 
button to the page, or adding an edit button next to each 
displayed object. Such changes are much simpler to perform 
using Web Content Server 800. 
Modifying Text/Graphics Look and Feel 

To change the look and feel of textual and graphical so 
information, the user can edit the view page in an HTML 
tool. The user can add <span>, <div> etc. tags around the 
components needed modification, and define the "style" 
attribute to reflect the desired look and feel changes. If the 
user needs to develop for browsers with limited CSS support 55 
(e.g., Netscape 4.x), the user can wrap the components in 
<u>, <b>, <font>, etc. tags as needed. 
Layout Changes 

The cut/copy/paste commands of tbe HTML editor can be 
used to perform most layout changes requiring the reposi- 60 
tioning of different components. Dreamweaver, for example, 
gives users powerful HTML/XML element selection capa- 
bilities that make it easier to move and copy whole HTML/ 
XML document fragments. 

Adding/Removing Information Content 65 

Often the model specification will result in the production 
of more content than needed by a particular view. For 
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example, the model for a page that needs to display the 
parents of a particular security domain only may also 
produce other information about the security domain (e.g., 
the description of the domain). This is especially likely when 
the model page reuses other, already existing command 
objects. In such cases displaying additional content can 
simply be done at the view page level: the user needs to 
place the newly required information somewhere on the 
view page. Removing information items is also very simple, 
since users can simply delete a particular HTML/XML 
fragment if viewing that piece of the model is not needed. 
Changing Look and Feel of Widgets Globally 

The use of widget libraries make it very simple to change 
the look and feel of widgets across pages. Either the widget 
transformation of the used widget library can be changed or 
an alternative widget library can be developed. In the latter 
case control pages must be updated to point to the new 
instead of the original widget library: 
Adding New Interaction Components 

If the guidelines for model page design are followed then 
adding new interaction components (e.g., buttons) is a very 
simple task. Adding a new widget (e.g., Cancel button) 
means adding a new widget to the widget section of the 
model page AND changing tbe view page to include the new 
widget. Since the widget section is a separate section of the 
model page, software engineers (and perhaps UI engineers) 
can make the required change without disturbing/interfering 
with any other part of the model page. 
Components of the Platform 808 

The control page associates a particular model page, view 
page and widget library. 

The model page produces the data needed for displaying 
the page and it also defines the widgets (interaction 
elements, such as links, buttons, input fields, etc.) and 
internationalized resources (labels, graphics) used by the 
view page. The model page has a well defined structure. 
Model pages can produce XML representation of data using 
command managers and command objects. A model page 
can invoke a command using a tag. After the model page is 
executed, the tag will be replaced with the XML data 
produced by the selected Command. 

The model instance is the XML document produced by 
executing the model page. 

The view page displays the data and widgets contained in 
the model instance (i.e. the XML document produced by 
executing the model page). If the control page declares a 
widget library to use, then the view transformation takes 
place after the widgets have already been transformed to the 
appropriate format (e.g. HTML). 

The widget library contains tbe display transformation for 
widget components. After the model page executes the 
produced widgets are transformed to the appropriate output 
format (e.g., HTML). The resulting HTML markup is 
wrapped in tags so the view transformation page can easily 
identify and place each widget. 

The tag library contains tags users can use in their model 
pages to access common code functionality. This common 
functionality includes accessing resource bundles, retrieving 
page parameters, executing commands, declaring widgets, 
etc. 

Control Page 

The entry point into any platform 808 page is an XML 
document that serves as a controller. This page is simply an 
XML document that points to the model, view, and widget 
documents. This convention creates a clean decoupling 
between the three constituent pages. As an example of the 
benefit of this approach, web content administrators may 
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substitute a different control page in a deployment environ- 
ment; this allows them to use the same model while modi- 
fying just the view. 
Coding Guidelines 

Pages built using the platform 808 employ certain con- 
ventions and coding guidelines to ensure consistent opera- 
tion and simplify some processing steps. These coding 
guidelines include the following: 

a. head Element 

All model pages must contain a head page element that 
defines some information specific to the model. It is used to 
capture the following: 

required metadata about input and pass-through param- 
eters 

values of il8n labels. The convention is that all il8n 
values are obtained via the il8n utility tag in the model 
page; this information is then passed on to the 
stylesheet in a predetermined location within the wdk- 
:head element 

page title and other useful information about the page. 

b. Widget Stylesheet 

The widget stylesheet is simply a list of xshincludes of the 
widgets used on this page. The widgets can be from the set 
of predefined widgets or can be customized widgets. 
One Example of a Preferred Embodiment 

In one preferred embodiment, the Web Content Server 
800 is a dynamic content generation framework based on the 
apache Cocoon project. Like other approaches, such as JSP, 
ASP, ColdFusion etc., the Web Content Server 800 would 
allow developers to create web pages to display data derived 
dynamically through some business logic. Unlike other 
dynamic content generation frameworks, the Web Content 
Server 800 separates the content from its presentation. This 
separation makes it easier to customize pages, to provide 
different versions of pages to different user agents (desktop 
browsers, handheld devices, etc.). 

Content production and presentation separation is 
achieved by following a Model-Mew-Widget (MVW) para- 
digm. In this paradigm three distinct components are respon- 
sible for generating the final output sent to the client 
(desktop browser, WAP phone, handheld device). The model 
page is responsible for producing the content as well as the 
user interaction components (widgets). Widget look and 
behaviors are added during the widget transformation. 
Finally the View transformation provides the look and 
layout for the content and widgets produced by the model 
page. 

File Loading Algorithm 

When the Cocoon engine processes the HTTP request, it 
invokes the getDocument( ) method of the file producer 
registered with Cocoon. Web Content Server 800 uses a 
specific file producer (SabaProducerFromFile) to load the 
requested file. This file producer uses SabaSite properties to 
determine the location of the requested file. To register the 
Web Content Server 800 specific file producer, the following 
line is added to cocoon. properties: 

producer. type. file- 
corn. saba. web. engine.SabaProducerFromFile 
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SabaSite 

SabaSite is an object containing a set of properties rel- 
evant to a particular saba application. These properties 
include, but are not limited to: 

File system location of application pages 
File system location of images 
Name of the site 

Name of the servlet driving this application 
Etc. 

Using the SabaSite object and the associated property file 
the configuration of a given Saba application can be changed 
with ease. 
15 The Algorithm 

The SabaProducerFromFile uses the request URL to iden- 
tify the file requested. The getDocument method of this class 
performs" the following steps:* 

1. Determines the SabaSite based on the request. The 
20 SabaSite is identified as follows: 

a. Extract the servlet path information from the request 
object using the HttpServletRequest API 
(getservletpath( )). 

b. If the servlet path ends with a Web Content Server 
25 800 specific string suffix, then the associated Saba- 
Site name is determined by snipping of that suffix. 

c. If the servlet path does not end with the Web Content 
Server 800 specific string suffix, then the system 
default SabaSite name is retrieved using the SabaSite 

30 API. 

d. The SabaSite is retrieved using the SabaSite API 

e. Finally the SabaSite is initialized using the request 
object 

35 2. Uses the SabaSite object to determine the location of all 
web documents by getting the document root property 
of the site. 

a. Uses the SabaSite API to retrieve the document root 
(getDocumentRoot( )). 
40 3. Determines the relative pathname of the requested 
document from the request object. 

a. Uses the HttpServletRequest getPathInfo( ) API. 

4. Computes the absolute path of the document by com- 
bining the document root with the relative pathname. 

45 a. Appends the value of the document root and the 
relative pathname. 

b. Replaces all "\" characters with to make sure the 
absolute pathname has the correct syntax. 

5. Parses the file identified by the pathname and returns 
50 the resulting document object model (DOM). 

ControlFile Processing Algorithm 

When a client sends a request to a Web Content Server 
800 application, the above-described process is used to 
55 identify and parse the control file. The control file is an RDF 
document that ties the above-mentioned three components 
of the Model- View-Widget paradigm together. 
Control File Example 



1 <?xml vereion="1.0" encoding-** UTF-8"?> 

2 <? co coo a- process type- M wdk"?> 

3 <! DOCTYPE rdf :RDF SYSTEM /control] 0.dttT> 

4 <rdf:RDF ImID8:roT-'•http://www.w3.org/3999/02/22-rtif-syn^JlI-as#' , 
xm\ra:^^^ u hiip-J/vr^^.^bQ.com/XMlJWDK"> 

5 <rdf: Description id-"searchPersoD~> 
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-continued 



6 <rdf:typc rcsourcc="http^/www^aba.com/3CMLyWDK/Contror7> 

7 <wdkrvcrsion>1.0<Avdtvcr8icm> 

8 <wdk:model ix3£resource-"searchPer8on.xrnl'7> 

9 <wdk:vicw rdf:resourcc-"scarchPeisonjcsr7> 

10 owdkrwidgets rdf:rcsourcc-".7xsl/widget/wd^_widgctsxsr/> 

11 <wdk:links> 

12 <wdtk:link modcl- u scarchPcrson.xmi" control-"scarchPcrson.idf 7> 

13 </wdk: links > 

14 </rdf: Description 



15 </rdf:RDP> 



The control file contains a Cocoon processing instruction 
(line 2) that is parsed by the Cocoon engine. The cocoon 
engine uses the processing instruction to look-up the pro- 
cessor it needs to use to process the document. The Web 
Content Server 800 installation contains tbefoUowing entry 
in the cocoon.properties file: 

processor.type.wdk- 

com.saba.web.engine.ControlFileProcessor 

This line tells the cocoon engine that the com.saba.we- 
b.engiDe.ControlFileProcessor java class is responsible for 
processing all documents that contain a cocoon processing 
instruction of type="wdk". 

The control file processor performs the following steps: 

1. Identifies the model, view and widget files. 

2. Parses the model file and creates a DOM representation 
of the XML document. 

3. Inserts in the model file DOM: 

Cocoon processing instruction to invoke the Web Con- 
tent Server 800 transformer after the model page is 
executed. The Web Content Server 800 transformer 
is responsible for transforming the result of the 
model page using the widget and then the view XSL 
stylesheets. 

XSLT processing instructions to declare where the 
widget and view transformation stylesheets are 
located. This information was extracted from the 
control file in step 1. 

4. Updates hyperlinks in the model file based link map- 
ping information found in the control file. 

The control file processor returns the document object 
model containing all these updates, and the Web Content 
Server 800 engine then processes this DOM. 
Identifying Model, View and Widget File 

The control file contains the following three properties for 
encoding the three files: 

wdk:model: the rdf: resource attribute of this property is 
the path to the model file. (See line 8 in the example 
above.) 

wdk:view: the rdf:resource attribute of this property is the 
path to the view file. (See line 9 in the example above.) 

wdk:widget: the rdf: resource attribute of this property is 
the path to the widget file. (See line 10 in the example 
above.) 

Creating the DOM for the Model Document 

Given the path information in the rdf:resource attribute of 
the wdk: model property, the actual path is computed based 
on saba site information. The process of computing the path 
is almost identical to the process described under the File 
Loading Algorithm section. The only difference is that if the 
value of rdf: resource does not begin with the path delimiter 
character ("/") then the processor interprets the path as a 
relative path from the control file. Once the path is 
computed, the model file is parsed and a DOM representa- 
tion is generated. 



Updating the Model DOM 

15 Before the model page (its DOM representation) can be 
further processed by the wdk engine, a cocoon processing 
instruction <?cocoon-process type«"xsp"?> is inserted. This 
processing instruction instructs me'engine to'first process the 
model page using the xsp processor (see section below on 

20 Custom XSP Processor). The control file processor inserts 
another processing instruction: <?cocoon-process type- 
"wdk__xsr?>. This processing instruction directs the 
Cocoon engine to use the Web Content Server 800 specific 
XSLT transformer for the transforming steps (see section 

^ below on custom XSLT processor). Furthermore, two 
<?xml: stylesheet . . . ?>processing instructions are also 
inserted in the document object model following the above 
processing instruction. The "href" data component of these 
instructions identifies the widget and view stylesheets in that 
order. The Web Content Server 800 specific XSLT trans- 

30 former will process these two processing instructions to 
perform the XSL transformations. 

The following Java code shows how the processing 
instructions are inserted into the DOM: 

private void insertNextPI (Document doc, Processingln- 

35 struction pi) throws 



ProcessorException 



NodeList nodcUst - docgetChildNodesQ; 
Node theNode-null; 
Node lastPI-null; 
// find last PI 

for (int i- node Lis t,getLength()-l ; i >- 0 ; i — ) { 
45 thcNode - nodeListitcm(0; 

if (thcNodcgetNodeTVpeO — 
Node.PROCESSING_INSTRUCTION_NODE){ 
lastPI-thcNodc; 
break; 
} 

50 } 

if (lastPI— null) { 

// cound not find a PI so just get the first node 

tbeNode-nodc List.item (0); 
} else { 

//going to do an insert Be fore, so we want to move to the next 
55 //node so that this new PI gets inserted AFTER the last PI 

thcNode-lastPLgetNcxtSiblingO; 

if (thcNode— null) { 
//should always have at least a root node after a PI 
throw new ProcessorExccption(" Error processing control 
rile: need a root node after a processing instruction"); 

60 } // if lastPI— null 

docinsertBefore((Node) pi, thcNode); 
} catch (DOMException e) { 
throw new t\ocessorException( M Uncxpected error processing 
control file: • + e.toStringOX 

65 } /' insertNextPI */ 
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Updating Link Information 

Model pages typically contain links that allow the model 
page to invoke another page. In order to make model pages 
reusable with different view pages, page references in a 
model page always refer to other model pages. This way 
different control files can reuse the same model page but use 
two different view pages. However, links pointing to model 
pages have to be transformed to control page hyperlinks 
before the final document is produced, since the request 
URL has to contain information about the control file and 
not the model file. In order to perform this transformation, 
the control file contains information about how to map a 
model page reference to a control page reference. The 
control file contains a single wdk: links element, which 
contains a number of wdklink elements. Each wdk: link 
element has two attributes: model and control The model 
attribute is the hyperlink name of a model file, while the 
value of the control" attribute is the' hyperlink namtTof the 
control file. 
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The control file processor locates the wdkilink and 
wdk: links elements in the control file DOM using the 
standard DOM API. Once all wdk:links elements are 
located, the control file processor inserts a wdk:linkMap 

5 element in the wdk:bead element of the model DOM, and 
then inserts one wdk: linkMapEn try for each wdk: link found 
in the control file using the DOM API. The wdk: linkMap- 
En try element has the same attributes as the corresponding 
wdk: link in the control file. This way the mapping informa- 

iQ tion is made available in the model page, and can be used by 
either the model page itself or the subsequent widget and 
view transformations. For example, the wdk: link widget 
makes use of this information to transform model page 
references to control page URLs. 

is EXAMPLE 

The Model DOM Before and After the ControlFileProcessor 
The following code sample shows the XML serialized 
version of a model file before the ControlFileProcessor ~ 
updated the DOM. 



<?xml version-" 1.0"?> 

<xsp:pagc language-*java" xmlnsrxsp="httpV/www^pachcx3rg/1999/XSP/Corc" 
xmlnsrwdklags=**http^Avww. saba.com/XML/WDK/taglib"> 
<xsp:6tiucture> 

<xBp:includc>coin.saba.exception.*</xsp incrude> 



<Axsp:stiucture> 

<wdk:page xinlnswdk-"httpV/wn^.saba.com/XMlVWDK''> 
<wdk:bead> 

<wditags:in> 

<wditags:param name-"sessioiiKey'7> 

<wdklags:param name="actkraKey" rcquiicd="felsc" typc="String" dcfault=*""/> 

<wdktags:param name="persooSearch"/> 
</wdJctags:ln> 
<wdktags:out> 

<wdfcparam name-" session Key" type»"SlringT rcquircd»**ttue"/> 
<wdl:param name="actionKey^ type^-String" required="£alse"/> 
<wdJqpaxam namc-"pcrsonSearch" typc-"String" rcquircd-"truc'7> 

</wdktags:out> 

<xsp:logic> 

Session aabaSession - SessionManagcr.getSession(sessionKey); 
String desiredLang - (String)sabaSession.getBlob("selectedLanguage"); 
</xsp:logio 

<wdktags:il8n.load icsource-**party_label3'*> 

<languagc><isp:e^r>d(3ircdl^ng</xsp:expr></laiiguage> 
</wdldags :il 8D.load> 

<wdfctUIe><wdktags:il8n. label ttame-"kH8n6000SearchForPeopleLabel'7> 

cwdkititlo 

<wdlc:labels> 

<wdk:label name- M busUaitLaberV<wdktags:il8n.label 
name-"kll8n6008BusiiiessUnitLaber7><vWk:label> 

<wdk:label name> H locLabe]"><wdlctags:il8n.label 
nnme-"kll8n6000LocationUber/><Avdk:lab<;l> 

cwdfclabcl name»"finlNamcLabcr , >cwdkt2gs:il8Q.lBbcl 
name-~kl 1 8n 6000 RegularFifstNameLabel'VxAwdk: label > 

<wdk: label oame- u la5tNameLabel"><wdktag8:il8D.label 
name-*1dl8n6000RegularLastNameLabcr7><^wdk:labcl> 

<wdfclabel name— "locationl^ber><wdJciags:il8n.label 
namo-^18n6000Regdarlx>cationLabel'7>^dk:label> 

</wdklabels> 
</wdfchead> 

<wdk:form method -"GET"> 
<wdfchiddcn_fie ld> 

<name>stssionKey</name> 

cvaluexxsp :ejqpr>sessionKey</xsp :cxprxvalue> 
</wdk hidden_field> 
<wdk:hidden_field> 

<name>actionKey<taame> 

<valuc>scarch </valuc> 
</wdk:hidden_fteld> 
<wdt: model> 

ocspilogio 
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if (actio nKcy^quals ("search")) 

{ 

<people> 

<wdk tags: execute 

niaDager>~com.sabaclieaLparty.beans.PersonCoinmaDdManager n command-~searchForPeople" 
aigume flt- M pcrsonSearch"/> 

<Vpeople> 
}/• if actionJCey.equal("search")'/ 
</xsp:logic> 
</wdUcmodel> 
</wdi:form> 
<wdk.*widgets> 

<wdk:tnput name-"lastNameFielcr> 

<labclxwdkiag?:ia 8a label name-*'kll8n600QLastNaineLabe )"/></labcl> 
<id>peisonSearch<yid> 

<valuc><xsp:cxpr>personScarch</xsp:eipr><ATilue> 
</wdlc input> 
<wdk:link name— "go"> 

<td>GO^/id> " " " " 

<hrcf>searchPersoo.xtnl </hitf > 

<typc>buttoa</type> 

<labclxwdktag?:il8n.Iabcl Dnmc-"kll8n6XXXXXGO >, /></Iabcl> 
<prompt><wdktags:il 8m label name-"kll8n6XXXXXGO"/></prompt> 
</wdk:liiLk> 
</wdk.-widgcta> 
</wdfcpage> 
</xsprpage> 



The following code sample shows the same model file 
after the ControlFileProcessor updated the model file. The 
changes are shown in bold face: 



<?xml version-" 3. 0'7> 

<?cocoon-process type="xsp"?> 

<7cocooE-pToccss type="wdk_jBl"?> 

<? xm hstylesheet href- M ./xsI/widget/wd k_widgetB.xsT?> 

<?xml:stylesheet hrcf-"searchPer50DJtsl"?> 

<xsp:page Ianguage="java" xrnins:xsp»~hUp://www.apache.org/1999/SXP/Core'' 
xminswditagc-"http:/Avww^ba.cxinVXMIVWDKAaglib''> 
<x5pstructurc> 

a.sp in elude >com .sab a . exceptio n. • </xsp : include > 



</xsp.structure> 

<wdk page xmlns:wdk="httpyAvww^ba.cxnn/XMlVWDIC , > 
<wdlc:head> 

<wdktags:in> 

ovdktagsrparnm name— **5cssionKcy*7> 

ovdktagsrparam name-^actionKey" rcquired»* 4 false" type-" String" defauli-*"'/> 

<wdktags:param name- 44 pereonSearch , 7> 
<wdktags:in> 
<wdk tag* rout > 

<wdk:param n&tnc-^aessionKey" type-"String" required-**tnie7> 
<wdk:param name— M actionKey> type-"String" required»"false"/> 
<wdk:param name-**peraonSearch" typc-**String" requircd-"true"/> 

</wdttags:out> 

<xsp:logio 

Session sabaSession - S ess ionM a n age r.getSess ion (session Key); 
String desiredLang - (String)BabaSes«ion.getBlob("eelected Language*'); 
</xsp:logio 

<wdktagB:il8n.load reBource-"party labels"> 

<languagc> <xsp:expr>desiredLang</sxp: expr> </language> 
</wdttags:il8n.load> 

<wdk:title><wditags:il8n. label name- M kll8a6000SearchForPeopleLaberV> 

</wdk:tUle> 

<wdk: labels > 

<wdk:label name»"busUnitLaber'><wdkUigs:il8n.label 
name- M K118m6008BiuincssUnitLaberV>^vdk:label> 

<wdk:label name-^locLaberxwdttagsrilSn. label 
name-"kll8n6000U>caaonLaber'/>-^^vdk:Iabel> 

<wdk:label narne-"rlrstNaineLabcr><wdlaags:Ll8n. label 
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namc-"kll8n6000Rcg^larHrsiNameUbcr7></Wdk:Iabcl> 

<wdk:label namc»" 4 lastNamcLabcr , xwdJttags:il8iLlabcl 
aamc-"kll8a6000RegutarLflslNDmcLabcrV></wdk:labc]> 

<wdk : label na mo" locatio nLabe r><wdkiags: il 8n. label 
aame* H ldl8a6000RegutarLocationLaber7><AvdJc:label> 
</wdk:labels> 
<wdk:linkMap> 

cwdkrllnkMapEntry model- M searchPersonjanr control> M searchPersoo.rdr/> 
</wdk:liDkMap> 

</wdk:hcad> 

<wdk:fbrm meLhod-~GET'> 
<wdk:hidden 5eld> 

<namoscssionKjcy</namc> 

<valuc><xsp:expr>sessionKey </rsp :expr></value> 

</wdk:hLddca fie td> 

<wdk:hiddcn ficld> 

<name>actionKey <J name > 

<value>Gcarch</valuc> 
</wdk:hiddcn_field> 
<wdk:model> 

otspilogio 

if (actionKeyxquals( w sc&rcb")) 

{ 

<people> 

<wdlctags:e3tecute 

maiBgcr»"com.saba.dicDLparty.beans.PeisonCtommandMaiiagcr command-lscarchForPecple" 
argument» M personSeatch M /> 

</pcoplc> 
}/* if action Key. equals("search**)*/ 
</xsp:logic> 
</wdk:model> 
</wdk:fbrm> 
<wdkrwvidgets> 

<wdk:input name— "las tNameFicld"> 

<labcl><wdktags:il8alabcl namc="kll8n6O00LastNaincLabcr7></labcl> 
<id>personSearch</id> 

<vulue><xsp:expr>peisoaSearch</xsp:expr></value> 
</wdk:input> 
<wdk:link name»"gp"> 
<id>GO</id> 

<href>scarchPersonjtml </hrcf> 
<±ype>buttoQ</type> 

<label><wdktags:il8ii.label mme-"ldl 8n6XXXXXG07> </label > 
<prompt> cwdktags il8rL label name«"kll8n6XXXXXG07></prompt> 
</wdk:liiik> 
<tfwdk:widgets> 
</wdtpage> 
</xsp:page> 



Custom XSP Processor 

Instead of using the XSP processor of Cocoon, Web 
Content Server 800 uses a custom XSP processor. To make 
this happen, the following line is added to the cocoon.prop- 
erties file: 

processor. type. xsp 

-com.saba.web.engine.SabaXSPProcessor 

This processor adds the following capabilities: 

Debugging: The Web Content Server 800 XSP processor 
can produce intermediate files representing the docu- 
ments as the model page is transformed from its 
original form to the java code that is executed and the 
actual data that is produced by the java code. These 
intermediate files can be inspected to locate the source 
of a problem more easily. 

Cache control: For debugging purposes it is important to 
know that the code that executes is the code that the 
developer has just edited. However, the cocoon engine 
contains a number of caching mechanisms that make 
this assumption incorrect sometimes (ie. The code 
that's executed is code that is in the cache instead of 
code that the developer has just changed). The Web 
Content Server 800 XSP processor allows control over 
caching. 



Producing Intermediate Files for Debugging Purposes 

The SabaXSPProcessor can produce intermediate files as 
the model file goes through the different transformation 
steps. The helper classes XSPDebugger and DebuggerCon- 
fig are used to control which if any intermediate files should 
be produced. The following properties are introduced in 
cocoon.properties for controlling debugging behavior: 

wdkdebugoutput 
wdkdisablecache 
wdkdebug 

The wdkdebug property can have the following values: 

off: No debugging information is produced 

full: Every intermediate file is produced 

wdktags: Only the result of the wdk tag library transfor- 
mation is output 

wdk: Only the result of the widget library transformation 
is output 

xsp: Only the result of the xsp transformation is output, 
model: Outputs the result of executing the java code 
produced from the model page. 
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The wdkdebugoutput property can have the following 
values: 

sourcedir: The output files are placed in the same direc- 
tory where the source documents are read from. 

browser: The output files are sent to the browser 

repository: The output files are placed in the cocoon 
repository directory. 

The wdkdlsablecache can either be "true" or "false*'. If 
true the cocoon cache is not used. 

The init method of the SabaXSPProcessor creates an 
instance of the DebuggerConfig class, and the process 
method creates an instance of XSPDebugger. The XSP De- 
bugger is a subclass of Debugger and it uses the Debugger- 
Config object to read the debugger configuration from the 
cocoon.properties file. 
The Debugger and XSPDebugger Classes 

The Debugger has the following API: 

public void readParameters(Dictionary parameters, 
DebuggerConfig config); 

This method initializes the Debugger with the current 
debugging property values, 
protected boolean debugThis(String rule); 

The method returns true if the wdkdebug property is 
either "full" or matches the rule parameter, 
protected boolean browserOnly( ); 

The method returns true if the wdkoutput property is set 
to "browser". 

public boolean cacheDisabled( ); 

Returns true if the wdkdisablecacbe is true. 
The XSPDebugger introduces the following methods: 
public boolean debugLogicsheet(String rule, Document 

document); 

Returns true if Debugger.debugThis(rule) is true AND if 
Debugger. browserOnly( ) is true. If only 
Debugger.debugThis(rule)is true, then first saves the inter- 
mediate result before returning false, 
public void debugFinalXSP(Document document) 

If the the wdkdebug property is full or set to model then 
the result of executing the code produced from the model file 
is output. 

Custom XSLT Processor 

The default XSLT processor that comes with Cocoon 45 
performs a single XSLT transformation only. However, Web 
Content Server 800 requires two XSL transformations after 
the java code produces the data. The first transformation 
replaces the widgets with their HTML representation (the 
widget transformation) while the second transformation 
renders the data (the view transformation). To make the 
engine aware of the Web Content Server 800 XSLT 
processor, the following line is added to the cocoon.prop- 
erties file: 

processor.type.wdk__xsl-com.saba.web.engine.WDK_ 
XSLTProcessor 

The Web Content Server 800 XSLT processor takes as 
input the document object model produced by executing the 
XSP page. The processor extracts the xml:stylesheet pro- 
cessing instructions from the DOM, and executes XSL 
transformations using the stylesheet documents referred to 
by the "href data element in the processing instructions. 
(The xml: stylesheet processing instructions were inserted in 65 
the source document by the control file processor — see the 
ControlFileProcessor algorithm section for details). After 



each transformation step, if the debugger flags are set, the 
DOM is serialized and saved to a text file. 

The following code snippet shows how the widget and 
view transformations are performed: 



try{ 

/* get all stylesheets referred to by this document */ 

Vector resources - gctRcsourcc3(documcnt > request, context); 

r apply each stylesheet in turn "/ 

Enumeration e - resourcesxlementsQ; 

while (c.hasMorcElcmentiO) { 

Object resource * e.nextElementO; 

this. logger. log(this, "Processing stylesheet " + 

resource.toStringO, Logger. DEBUG); 
Document stylesheet - getStylesheet( resource, request, 

!xsltDebugger.cacheDisabled0); 
Document result = Uiis.par5eLcrcatcEmptyDocument(); 
document - transformer.transfonn(document > null, stylesheet, 

resource.toStringO, ttsa K params); 
if (xsltDebuggeLdebugStylesheetCdocumcnt, resource)) { 
//requested debug output to browser, so done now 
return document; 
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} 
} 

return document; 
} catch (PINotFoundException e) { 
return document; 
} 



Custom XSP Page Class 

Each XSP page (model page) is transformed to a java 
object (source code generated, compiled and the class is 
loaded). In Web Content Server 800 the generated java 
objects are instances of the SabaXSPPage class, which is a 
subclass of the XSPPage class. (The XSPPage class is the 
default class provided by Cocoon.) In order to change the 
class from XSPPage to SabaXSPPage, the following 
changes had to be made: 

1. Create a new xsp-java.xsl taglibrary stylesheet based on 
the default stylesheet that comes with Cocoon: 

a. Change the class declaration line to extend SabaX- 
SPPage instead of XSPPage as follows: 

public class <xsl: value of select-" @name"/>extends 
SabaXSPPage { 

b. Invoke the initialization method specific to SabaX- 
SPPage in the populateDocument method: 
initializeOnRequest(request, response); 

This method initializes protected site and logger vari- 
ables. (See below) 

2. Change the cocoon.properties file by adding the fol- 
lowing line: 

processor.xsp java.logicsheet-/com/saba/web/engine/ 
xsp-java.xsl 

The SabaXSPPage class provides model pages access to 
frequently needed information including: 
Site: information about the SabaSite object representing 

the current saba site. 
Path information: extracted from the Saba site object for 

convenience 

Access to a logger for debugging and status messages 
SabaXSPPage declares protected member variables for 
each: 

protected SabaSite wdkSite; 
protected Logger wdkLogger; 
protected String wdkBaseURL; 
protected String wdkRoot; 
These variables are therefore accessible by model pages 
and by the tags defined in the wdktags tag library. 
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Structure of Model Pages 

Model pages are Extensible Server Page (XSP) pages. 
XSP pages can contain a mix of static content and content 
generating programming logic by using xsp directives (tags) 
defined in the xsp tag library. Furthermore, an XSP page can 
make use of an indefinite number of application specific tag 
libraries. A Web Content Server 800 model page uses the 
wdktags tag library to simplify certain common program- 
ming tasks. 

Web Content Server 800 model pages have a very well 
defined structure. The document element of the page is 
<xsp:page>. The document element can contain <xsp:struc- 
ture> and other xsp directives, but it can contain a single 
non-xsp element only. For a Web Content Server 800 page 15 
that element is wdfcpage. The wdkrpage element consists of 
the following subsections: . , . , , 

wdk:head-— contains internationalized labels, the page 
title, image references, link mapping information 20 
(generated automatically from the control file by the 
control file processor). 
wdk:form — The wdk:form element is one of the elements 
in the widget library. Since most wdk pages are HTML 
forms, the wdk:form element is used to generate the 25 
HTML form and javascript functions required by a Web 
Content Server 800 application. For example, a javas- 
cript function is generated that can be called by link 
widgets to submit the form. 
wdk:widgets — widgets (input fields, buttons, hyperlinks, 

etc.) are all listed in the wdk: widgets section. 
The wdk: form element can contain the declaration of 
hidden fields needed by the application, and it contains a 
singe wdk: model element. The wdk: model element contains 
all "data** generated by the page. 

Often all the wdk: model section contains is invocations of 
Commands that produce the appropriate XML content. 
Separating Content from Interaction 

An important property of model pages is the ability to ^ 
generate/declare dynamic content (through commands) and 
interaction elements (widgets) independendy of each other. 
This separation of content and widget generation allows for 
greater reusability. However, at the end of all the processing, 
the widgets and the content have to be combined. For 45 
example, an input text field (a widget) and the "name" 
property of a business object have to be connected/combined 
some way to make sure that that particular text field can 
display that particular property. This connectivity between 
model elements and widgets is achieved by Web Content 
Server 800 tag library tags. 

The wdktags: attachTo tag can be used to "attach" (copy) 
a particular widget to a model element 

For example, a software engineer may author the follow- 
ing simple model document: 
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<wdk model> 
<domain> 

<nnme>Domain 3</name> 
<id>idl</id> 
</domain> 
<domain> 

<name>Domain 2</name> 
•ad>id2</id> 
</domain> 
</wdk:model> 
</wdtfonn> 
<wtflcwidgets> 

<wd3e input name= "cditNamc"> 

■cwdkta gs :attachTb path- u domain'7> 
<value><wdktags :nodcRcf path«» "name"/></vahie> 
</wdk:input> 
</wdfcwidgets> 

<ftsp:pago 



The document resulting from processing the Web Content 
Server 800 tag library and the XSP engine execution will be: 



<wdkpage> 
<wdkhead> 
</wdkJiead> 
<wd3cform> 
<wdQcmodel> 
<domain> 

<namc>Domain ]</namc> 
<id>idl</id> 

<wdk: input name= ~editName~> 
<vahie>Domain 1 </value> 

</wdk:input> 
</domain> 
<domain> 

<m mo Domain 2</name> 

<id>£d2</id> 

<wdk:input name- M editName"> 
<valuc>Domain 2<fvalue> 
</wdk:input> 
</domain> 
</wdk: model > 
<^wdk;fonn> 
<wdk:widgets/> 
</wdk:pagc> 



<xsp:pa g e language- -Java" 60 N ° tC ^ alUCh T ° difCCtive cffcctWcly Created a copy 

xmio3:xso-* , htto:/Avww.ai)achc.Qrg/i999/xsp/CQre " of the input widget inside each domain element. 

^ xmlD3:wdtiaffl ^ttt> : /rww . S ^ l C fim^Ml/wnKft fl fl.V Furthermore, the nodeRef directive has been replaced with 

<wdk:pagc> the text value of the element it refers to in its path attribute. 
<wdk hcad> 

</wdfchead> ^ 

<wdfcfonn method- -posTV The followmg describes the implementation of the 

attachTo tag. 
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1 <xsl:template match-^fwdktagmtachTbJ^ 
1 <xsl rvariable name> H fDOtNode"> 
<xal:choose> 
ccslrwhen test-*wdktags iauachTb/@root~> 

<xs I .-vahie-of select-"wdktags attachTo/@roof '/> </xsl rwhe n> 
<xsl:otheiwise> 

WDKDomUtiU.gctModclNodc(xsp<^cntNodc.gctOwiicrDocumcntO. 
getDocumeotElementQ) 
</xsl:olherwisc> 
^xskchocso 
</xsl:variable> 

3 <xsp:logjo 

list wdkNodes - WD KDomUuls.gclNodes((Elcment)<xsl rvalue -of 
sclcct-"$roolNodc'7>,"<XBl rvalue -of eclcct-"wdilags:aUflch7b/@path "/>"); 

4 if (wdkNodes — null) { 

throw new Run time&ception ("Could not find node: <xslrvalue-of 
select-"wdktags:attachTo/@path7>"); 
} 

Iterator wdklter « wdkNodes iicraiorO; 
whiJe (wdk£ter.hasNextO){ 

5 wdkwidgetNode - (Node)wdkIter.nextO; 
wdktags NodeStack.push(xspCurrentNode); 
xspCunentNode - wdkwidgetNode; 

6 if (xspCurrcQtNodc — du11){ 

throw new RuDtimeException("Null node in node list"); 

} 

7 <xsp xoatcnt> 

<xsl:copy> 

<xsl:apply-templates select™" *|@*"/> 
<tfjcsl:copy> 
</xsp:content> 

8 xspCunentNode » (Node)wdktagsNodeStack .popQ; 
} 

} 

</xsp:logic> 
</xsl:template> 



35 

Line 1 specifies the match condition: this template will section 3. In section 5 the current xsp node (the value of the 

match any element that contains a wdktags: attachTo sub- xspCurrentNode variable) is saved on a stack, and its value 

element. Section 2 contains XSL logic for determining what is replaced with the next node from the set of nodes returned 

root element should be used as the starting point for the in section 3. Since the XSP processor uses the xspCurrent- 

value of the path attribute. If the developer specifies a root ^ Node variable to mark the current "insertion point" — i.e. the 

attribute, then the value of that attribute is used, otherwise location where the next DOM node will be inserted in the 

the root element defaults to the wdk: model node of the Document, this operation effectively copies the current 

model page. Section 3 invokes the getNodes( ) method on subtree (the widget) to each node returned in section 3. 

the WDKDomUtils class. That method returns the set of (Sections 6 and 7 perform the actual copying.) Finally, 

nodes that can be accessed from the root node through the 45 section 8 restores the value of the xspCurrentNode and 

path given in the path attribute of the wdktags:attachTo resumes the iteration. 

directive. Section 4 checks for error conditions and sets up The following section describes the implementation of the 

the iteration through the set of DOM elements returned in nodeRef tag. 



1 <xsl: template matcb> M wdktags:nodeRef > 

2 <xb1 rvariable name-*root"> 

<jtsl:choose> 

<xs!:whcn tesL-"@source"><xsl rvalue-of selcct- M @source7></xsl:when> 
<3Bl:othcrwisc>wdkwidgetNode^xsl:otheiwise> 
</xsl:choose> 
</xsl:variable> 

3 <xsp:logic>{ 

Element wdkChildNodc - WDKDomUtils. getChildNodc((Element)<jcsl:vaIue-of 
s€lecl-"$root"/>,"<xal:value-of Belect-@path M />"); 
<xsp:conUnt><xsp:expr>WDKI>3mUtUs.ge^ 
} 

</xsp:logio 
</xsl:template> 
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Line 1 specifies the match condition: this rule matches 
every node Ref tag. Section 2 determines the root node: if the 
source attribute is given then the value of that attribute is 
used, otherwise the value of wdkwidgetNode Java variable 5 
is used. The wdkwidgetNode variable is initialized in the 
wdktags:attachTo template described above. This way, if 
nodeRef is used in the context of an attachTo tag, the root 
node is the same node the widget is copied to. The actual 
node whose value is needed is located by following the path 10 
from the root node. Finally, the text value of the node is 
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element, the <head> element containing the <title> element. 
These common templates are all grouped in a default 
stylesheet that can be imported using the <xsl: import > 
directive by every view page. As a result, for simple pages, 
the view page needs to contain a singe cusomized xsl: tem- 
plate rule that matches on the "wdk:moder node. This 
template is responsible for rendering the data as well as the 
widgets. 

EXAMPLE 
Default View Transformation Templates 



1 <?xml vcision="1.0"?> 

<x&l:stylesheet version ="1.0" xmlns Dcsl-'http ^A^^ww. w3.org/l999/XSL/Transform" 
xmlns rwdk-^httpi/Avww. saba. com/XM L/WDK"> 
<xsl:output mcthod»**xml" indenlVycs"/> 
<xsl:s trip-space elements-" *"/> 

2 <xsl:tcmplate match-T*> 

OEslrvariablc name ="titleLabcl"><xsl rvalue -of scl cct="//wdk: hcad/wdk : titlc"/> </xsl rvariab le > 
<himl> 
<head> 

<titlo<3Calrvaluc-of sclcct-"$tiUeLabcl"/><VtiUc> 
</head> 
<body> 

oibI apply-templatcs/> 
</body> 
</html> 
</xal:tcmplatc> 

3 <xsl template match="* j @*t teJrt Ol commciIt O" priority="-l"> 

<xsI:copy> 

<xBl:apply-templates select-"* | @*|text0|cominent0'y> 
<Acsl:copy> 
</xsl :template> 

4 <! -eliminate the wdk: bead element and all children of wdkwidgets~> 
<xsl: tern plate match=wdk;head | wdk :wid gets > 

</xsl:template> 

5 <! -replace widget with span (so we can do CSS on it) and process their children- > 
<xsl:template iratch»'Nvdk.*widget"> 

<span class=**{@name}"> 
<xsl :app ly-templateB/> 
</span? 
<br/> 
</xsl:template> 

6 <xsl template match« M wdk:page M > 

<xsl:apply-templates/> 
</xsl:template> 
</xal:stylcshcct> 



computed by calling the WDKDomUtils.getTextvalue( ) 
method. 

Structure of View Pages 

View pages are XSLT stylesheets. The role of the view 
stylesheet is to convert the XML document produced by 
executing the model file (and the subsequent widget 
transformation) to a format understood by the user agent. 
For example, for desktop browsers this typically means 
conversion to an HTML representation. Since model pages 
have a well-defined structure, view pages are also highly 
regular. For example, there are a number of model page 
elements that should not be rendered (such as wdk:head 
element and its content should not be copied to the output). 
Other model pages nodes have a standard representation in 
HTML (or in the desired output format). For example, the 
rule for rendering wdk:page is to generate the <html> 



50 Section 1 defines the namespaces used in the stylesheet. 
Section 2 defines the root level template. This template 
produces the html tags, and generates the html head element 
complete with the title element. Section 3 defines the default 

55 template: every element, attribute, text and comment is 
copied to the resulting document, unless a more specific 
template provides different instructions. Section 4 specifies 
a template for eliminating the wdk:head and wdk: widgets 

60 elements and their contents (since the contents of these tags 
should not be rendered using the default template defined in 
section 3). Section 5 introduces a template for transforming 
every widget by wrapping them into a span element replac- 

65 ing the wdk: widget "wrapper*'. This makes it possible to use 
CSS styling on a per named- widget basis. Finally, section 6 
defines the template for processing the wdk:page element. 
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A View Page Example 



1 <7xml version-"1.0"?> 

<xsl:styieaheet version- 44 !.*)" xmlns3t5l- 44 httpV/www. w3.org/a999/XSL/Tran3fonn" 
xmlnswdi- M hUpV/www.saba.com/XML/WDK ,, > 

2 <xsl:import hief-7.JtsI/view/woX_defauItviewjcsry> 

3 <xsl:template match- M wdk:rriodel"> 

4 <h2 aIign-"center"><xsl:valuc-of sc led-" Avdi rr^ge/wdk : head/wdl rtitle ' '/></h 2 > 

5 <p> 

<xsl:\^ruc><>f selea-"/wd&:page/wdk:head/wd^^ 

6 <xsl:for-each selcct> M parents^parcnt M > 

<xslrvarue-of selectVname'7> 
<xsl:text>&gc, </xs!:text> 
</xsl:for-cach> 

<xslrvahie-of select=**parcn.ts/leaf/name , 7> 
</p> 

7 <xsl:apply- templates sclcct^'7/wdk .-widget "/> 

8 </xsl:template> 
</xsl:stylesheet> 

20 

Section 2 imports the stylesheet containing the default managing the connectivity between widgets and the pro- 

templates. Line 3 defines the rule for processing the wdk- duced data model, 

:model node. Line 4 displays the title of the page by managing the input and output parameters to the model 
accessing the wdk: title tag inside the wdk: head tag. Section P a g e > 
6 iterates through each "parent" element inside the wdk- 25 etc - 

:model element and displays its name. In section 7 any To makc librarv accessible by the processing 

widget produced by the model page is displayed. me following line is inserted in cocoon.properties: 

The wdk Taglibrary processor.xsp!ogjcsheet.wdktagsjava-s:/sys/jav a/web/ 

The wdk taglibrary contains a number of tags to simplify com/saba/web/xslAagHb/wdk^taglib xsl 

the development wdk model pages. The tag library includes 30 The value of the aboveproperty identifies the location of 
taes for* the taglibrary stylesheet. The taglibrary stylesheet contains a 

g number of xsl:import directives to import templates respon- 

handhng resource bundles for page internationalization, sible for implementing subsets of tags and it also contains a 
invoking commands to generate XML representation of number of default templates, as the code example below 
the data retrieved from the database, shows: 



<7xml version-" l.CT cncoding="UTF-S"?> 

<xsl: stylesheet vers ion=** 1.0" rmlns3sl«-"http:/Avww. w3.org/1999/XSUTransform'* 
Km Ids :xsp— "http://www.apache.org/1999/XSP/Core'' 
xmlns:w^tags-"http://ww^ 
rmlns rwdk-"rUtp://www.saba.corn/XMLVWDK"> 
•ccsl : preserve-space elements-* 4 *"/> 
<xsl: include href°"wdk__param.xsr7> 
<xsl: include hrcfV 4 wdk^_i:l8n.rsr7> 
<xsl: include hrcf- M wdk_command.xsl"/> 
<xsl: include hrcf- H wdk_control.xsl7> 
<xsl: include hrcf-"wdk_sitejsl" /> 
<jcsl:temp[ate match- 4, xsp:page'*> 
<xsl:copy> 

<!-need to explicitly call some logic in the wdk_command stylesheet — > 
<xsl:call- temp late name-"cornmand_header"/> 
<1— need to explicitly call some logic in the control stylesheet --> 
<xsl:call- temp late name-"control_header , 7> 
<xsl :apply-templates/> 
</xal:copy> 
</xsl:template> 

<xsl: template match-"®* |*|textO [processing- instructionQ|cornmentQ" priority- 4 *-!^ 
<ral:copy> 

<XBl:apply-templates s€lect»*'@*|*|textO|p^occssirlg-instmction()|cornmentO , *^ 
</xsl:copy> 
<fm\ :template> 

<xsl:template match- 4t wdk:head t '> 
<xsl:copy> 
<wdk:Bite> 

chrcf>/<Dcp:cxpr>wdtRcot<^xsp:cxpr>/</hrcf> 

<imageRoot><xsp:expr>wdxSite.getI mageRoot0</xRp :expn></imageRcot> 
<sabaseTvlet><csp:expr> WDKSainU til. getAssocaatedSaba^ 



<sitena me> <xsp :expr >wdkSite.getNameQ </xsp:expr> </sitena me> 
</wdk:aite> 
<xsl app ly-te mpl ates/> 
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-continued 



</xsl:copy> 
</xsllcmplalo 
</xsl styles heet> 



An Example: wdkta^s: param 

The wdktags:param is one of the tags defined in the wdk 
tag library. The purpose of this tag is to simplify the 
extraction of parameters from the HttpServletRcquest 
object. Traditionally, JSP, XSP or servlet programmers have 
to write a number of lines of code for the parameters they 
want to process. The code for each parameter is typically 
similar to the following: 



Each parameter can be defined with a single line of XML 
code and as a result of this line the developer can use a Java 
variable named "param" in their code wherever the value of 
the "param" HttpRequest parameter is needed. The wdktag- 
srparam tag is implemented in wdk param. xsl. and is 
imported by the main taglibrary stylesheet. The following 
code shows the implementation of wdktags:param: 



1 <?xml version-" 1.0" encoding-"UTF-8"?> 

ocslistylesheet version-"" 1.0" xmlns^-"http^/www.w3.oig^l999/XSi/nansform" 
xmlns rxsp-*' http -J /www. apache .org/1 999/XSP/Corc" 
xmlm:wdtetags-"http;//w^ 

2 <xsl template niatch-"wdlaags:LnAvdtoflgs."param**> 

3 <xsp:logio 

<xsl variable name-"paramName"><xsl:v&roe-of select-"@name'7></xslrvariflble> 
<xsl:variabic name= M paramTypc"> 
<xsl:choose> 

<7£sl.-whcn tcst-"not(@typc)">Stririg</xBlrwhea> 
<xsl:when test-"type-'ID"*>String </xsl:when> 
<xsl:otherwisexxst^alue-of select-* , @type'*/></xsl:oLherwise> 
</xsl:choose> 
</xslrvarinblc> 

<xsl : variable came»"paramRequiie<f"> 
<xsl:chooGe> 

<xsl:whcn tcst="not(@rcquircd)">felsc</)islnyhcn> 
<xsl:otherwise><xsl rvalue -of selecl=<@**required'7></xsl roLherwise> 
</xsl:choose> 
</xsl:variab)e> 

ocslrva liable name="paramDefauJ f> 
<xsl:chooBe> 

oeshwhen tc»t="@de£ault!=""><xslrvalue-of sclcct-"@default , 7> < ^xslrwhcn> 
<xsl:whcn tcst="@default="">"*'<Acslwhen> 
<xsl:when test- w not(@default) and @type= ' String' "> m, <Jxs\ :whe n> 
<xsl:othcrwisc>null/xsl:otherwisc> 
<tol:choosc> 
</xsl:variable> 

4 <xsl:valuc-of sclcct-"$pftrarnTvpe7><xsl:text> </xsl:text><xsl:value-of 
Belect="$paramName"/>»re^esLgetPajrameter("<3csI:value-of sdect- *$paramName"/>**); 

if (<xsl:value-of seIect="$paramName F 7> — null) 

<xsl:value-of select^SparamName"^ - <xsl:vaIue-of 5elect-"$paramDefault"/>; 

</isp:logio 
</xsl:temp!ate> 
</xsl:styiesrject> 



String paramorequest.getParameter("param"); 
if (param— null) {param="some default"; } 

The wdktags:param tag intends to simplify this by allow- 
ing developers to declare what parameters they want to use 
in the model page, and the mundane task of extracting the 
parameter is performed by the tag itself. Thus, Web Content 
Server 800 developer can write the following in the <wdk- 
:head> section of the model page: 



Section 1 declares all namespaces used in the stylesheet. 
In line 2 the match condition is given for the template. This 
template matches on every wdktags:param tag inside a 
wdktags:in tag. This nested condition is necessary, because 
a different template may transform wdktags:param tags 
inside the wdktags:out tag. Section 3 computes the values to 
use for parameter type and parameter default value. These 
values are either determined from the values of "type" and 
"default" attributes of the wdktags:param tag, or default 
values are selected (the java String class for type, and the 
java null constant for default). Section 4 produces the java 
code declaring the java variable by the name given in the 
"name" attribute of the param tag, and the value is initialized 
either from the HttpServletRequest object or by using the 
default value computed in line 2. 
Tags Defined in the Web Content Server 800 Tag Library 

wdktags:param Provides a convenient method for declar- 
ing and using parameters passed in through the HttpServ- 
letRequest. 



60 

<wdktags:iB> 
cwdktagsrperam name- "param" type- "String"> 
default- "some default" required- "truc'7> 
</wdktags:irj> 65 
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wdktags: si teRef: Generates an absolute URL from a rela- 
tive URL based on the current site information. 

wdktags: execute: XML fragments produced by Java 
objects (Commands) can be embedded in the resulting 
model document using the execute tag. 

wdktags: il8n. load: Declares the il8n resource bundle to 
use for the labels in the page. 

wdktags: il8n.path: Generates internationalized image 
path information using site parameters and information from 
the resource bundle specified by wdktags:il8n.load. 

wdktags: il8n .label: Retrieves internationalized labels 
from the resource bundle specified by wdktags:il8n.load. 

wdktags: attachTo and wdktags:nodeRef: As described 
above these tags can be used to assign widgets to model 
elements and to add data dependent information to widgets. 

wdktags: repeat: Provides the capability to replicate wid- 
get components based on elements in the generated model. 
Used mainly by list widgets to generate the set of options 
dynamically. 
The Widget Library 

The Web Content Server 800 widget library co ntains rule s 
(XSLT templates) for transforming a number of widgets to 



10 



get information from the user, he or she needs to use the 
wdk input widget. Here is an example of using the input 
widget: 



<wdk:input name- "inputZip"> 
<id> inputZip </i d> 
<size>5<^size> 

<maxlcngth>5 </maxlcngth> 
<value>6O202</value> 
<label>Enter the zip codc</label> 
<required>false </required> 
<password>false</password> 
</wdk:input> 



20 The widget transformation transforms this document frag- 
ment to the following: 



<wdi.:widget name»"inputZip"> 
<span align- "left" class- "Input_Label">Entei the zip 
code</span> 

  

cspan align- "left" class- "Input_Field"> 

<input type- "text" name- "inputZip" size- "5" maxlength- "5" 
value- "602027> 
</span> 
<Avdkrwvidget> 



their HTMT representat ion. The^widp etJibi ary provides a 35 
leyeLoLa hstraction between the_ujexjn teraction com ponent 
(e.g.aj jext input fi eld) and its presentation (e.g., an HTML 
inputfielS or a WML input field). This way the content 
producing model pages can be reused by different control 
files — one may deliver the content to a desktop browser ^ 
using the HTML widget library, while another may deliver 
the same content to a handheld device using a modified 
version of the widget library (e.g., using WML). 

The widget library contains widgets for most commonly 
used inputs and controls, such as: 

Buttons and links: The link widget can be used to display 45 
an image button or regular hyperlink; 

List widgets: the list widget can be used to display 
common drop-down menus, set of radio boxes or set of 
check boxes; 

Input widgets for entering and displaying text values and 50 
passwords; 

Hidden variables: for storing values in the webpage 

without displaying them; 
Etc. 

An Example: wdk:input 55 

The wdk:input widget represents the abstract notion of a 
text field. If the model page developer needs a text field to 



Note that the transformed version of the widget is 
"wrapped in to "wdk: widget tags, this makes it very simple 
for the view transformation to reference the entire widget 
(e.g. by using <xsl:apply-templates select="wdk: widget 
[@narne~'inputZip , ]/>). Also note that the label and the 
field parts of the widget are wrapped in <span> tags with the 
class attribute set to Input_Label and Input_Field, respec- 
tively These class attributes can be used to customize the 
look and feel of the input widget by using Cascading 
Stylesheets (CSS) or by writing specific XSLT templates in 
the view transformation. For example, the following view 
transformation template will set all input labels in the page 
to use Arial font: 



<xsl:template match- u span(@cla8&- 'Input_Laber]"> 
<span style- " font-family :Ariar> 

<xsl:apply-templates select- "**7> 
</sspan> 
</x3l:tcmplate> 



The wdk: input widget is implemented as XSLT templates 
as shown below: 



50 



1 <xsl:template match-" wdk: inpuT> 

<xsl:variab!e nnme-"fonnElement"> 
<xsl:choosc> 

oolrwhen test-^booleanfid)'^ 

orelrvalue-of select-" norm alize-space(id)"/> 
<tal:when> 
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<xsl:otheiwise> 

<xslrvalue-of selccti-**@name"/> 
</xsl:otherwisc> 
</xsl:cbocse> 
<tfxsl:variable> 

2 <wdk.*widget namc-"{@namc}"> 

3 <span align-^lcft" class-"lnput LabeT> 

4 <xsl:if test-"required" 'TRUE*^ 

<xsl attribute name-"fltyie">colorTed</xsl:aUribute> 

<xslrvahjc-of select «"IabeT7> 
<span> 
< 

5 <span align-" left" class-"InpuL_Field**> 

<xsl:chooee> 

<xslrwbcn tcst» a normalizc-spacc(pa5sword)-' truc'"> 
<input name»"{$formElement}" type- M password"> 
<xsl:call-template name-"input_attributes'7> 
</input> 
<tal:wlien> 
<xsl:otherwise> 
<input name-"{$formElement}" typc-"tcxf *> 
<xs):call- template name="input_aurlbutes*7> 
</inpui> 
</xsl:othcrwi3c> 
</xsl:choosc> 
</span> 

6 </wdk:widgGt> 
</xsUcmplato 

7 <xsl:templat£ namc="input_attributcs"> 

<xsl:if test-"boolean(sizc)"> 

<xsl:attribute namc="sizc**><xslrvahjc-of sclcct="normalizc-space(size)'*/></xsl:aitributc> 
<^xsl:if> 

<xsl:if test-"boolean(maxleiigth"> 

<ssl: attribute namc= - maxlcngtli >> ><xsl rvalue-of sclcct"Dormalizc-spacc(max]cngth)"/></xsl:attiibutc> 
</xsl:if> 

<xsl:if test-"boolean(value) w > 

<xsl:attribute namc= M valuc' , ><xsl rvaluc-of sclcct^"ixirmalizc-spacc(valuc)"/></xsl:attributc> 
</xsi:if> 
</xsl:template> 



Section 1 contains the match condition for the template: 
every wdk: input element in the document will be trans- 
formed using this template. In section 1 the name of the 
input field is computed as well. Section 2 shows that this 
widget Oust like all the other widgets) is nested inside a 
wdk: widget element, which makes it simpler to place wid- 
gets in the view transform. Section 3 shows bow the 
different components (the label and the actual text field) are 
embedded in an HTML span element. In section 4 the color 
of the text label is determined based on the "required** 
sub-element of the wdk:input widget. The logic in section 5 
determines what type of text field to generate: either "pass- 
word" or regular "text" field. Section 7 shows the template 
called from section 5 to fill in the attributes of the generated 
HTML input element. 

list of Widgets Defined in the wdk Widget Library 

wdk:hidden element: Represents an HTML hidden ele- 
ment. The widget generates the required element and Java- 
script functions that can be invoked to set the value of this 
element. 

wdk: form: Generates the HTML form element and Java- 
script functions needed to manage the form. 

wdk: input: Represents a single line text element. Can 
render the widget as a PASSWORD or TEXT HTML form 
field. 

wdk:list: Represents a widget for selecting an item from 
a set of predefined items. Supports four different HTML 
renderings: 

Dropdown list 

List box 



Checkbox set 
Radiobutton set 
40 wdk:link: Represents a link or button. Besides submitting 
the form, the fink widget can be used to: 

Pass parameters with the invoked URL using <field> sub 
elements; 

Execute an unlimited number of javascript functions 
45 before (or instead of submission; 

Open popup-windows and initialize the popup-window 
variables. 

Process the data returned by the popup window invoked 
by the link 

50 Commands 

Model pages are responsible for producing an XML 
representation of the content of the page. This content 
typically comes from executing complex business logic 
(e.g., running database queries, exercising business APIs, 

55 etc.). Although model pages (being XSP pages) are capable 
of including programming logic, including a large amount of 
code in an XSP page makes it hard to maintain. To solve this 
problem Web Content Server 800 introduces an implemen- 
tation of the Command pattern (Gamma et al.). A developer 

60 can invoke a command from a model page by using the 
execute Web Content Server 800 tag library tag. For 
example, the following line <wdktags:execute manager- 
"CatalogCommandMgr" command="search"/>invokes the 
execute method of the ICommand object registered under 

65 the "search** key of the CatalogCommandMgr and replaces 
the element with the XML result of executing the method. 
Here is the implementation of the wdkags:execute tag: 
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<?xml vcreions-"l.(T7> 

<xsl stylesheet version-** 1.0" xm!ns^l»"bttp^/wTOw.w3.orgA999/XSl/rransform** 
xmlnfl3^- u http*//www.apache.org/l 999/XSP/Core" 
xmlns*wdktags- u http7Avww.saba.co m/XM L/WDKAaguV> 
<xsl: template name-"command_header"> 
<z8p*structure> 

<isp:inchxjc>cDiiiiaba.xmJ."</x5p:inchjdc> 
<zsp*inchxJe>ooin^ba.web.dlc.*</xsp:include> 
</xsp structure > 
ccspdogio 

(Command and - mill; 

private | Command ge tComma n d(Strin g mngrName, String cmdName) 
throws Exception { 

Class mngrOass = Class. forName(mDgrName); 

jCommandManager mngr - (]CommflndManager)tnngrClas8.ncwIastancc(); 
return cmd «■ mngr.getCommand(cmdName); 

} 

Node execute Command(String mngrName, String cmdName, 
HttpScrvletRequest request, HttpServletResponse response, 
Document document, Object argument) 
throws Exception { 

String Writer writer - new String Write r(); 

KMLVisitor visitor - XMUgetDcfaultXMLVisitor(writer); 

cmd - gctCommand(mngrName, cmdName); 

if (argument !- null) 

cmd.exeaitefrequest, visitor, argument); 

else 

cmd.execute(request > visitor); 
String xml = writer.toStringO; 
if (xml.lengthO != 0) { 

InputSource source - new InputSource(new String Reader(writer.toStringO)); 

XercesPaiser parser - new XercesParserO; 

Document doc = parser.parse(source, false); 

return documenLimportNode(doc,getFiistChild(), true); 

} 

else { 

return null; 

} 

} 

<^xsp:logic> 
</xsl:tcmplato 

<xsl:template matcb=**wdttags:execute"> 
otslrvariable name-* 1 returnVariable> 
<xsl:choose> 

<xslrwhen test=**boolean(@returay*xxsl rvalue -of select=**@return"/></xsl.-woen> 
<xsl:otherwiBe>wdk£xecuteRetuni<xslrvalue-of select-*generat^id07><^xslx)therwise> 
</xsl:choose> 

</xslrvanable> 

•crspdogio 

Node <xsl:valuc-of selectV$rctunivariable"/>; 
</xsp:logic> 
<xsp:logio { 

String wdkMngrName - "<xal:value-of select-* 4 manage r7>"; 
String wdkCmdName - "<xsl:value-of select^"@command'7>"; 
Object wdkArgument - null; 
oshif test- 44 boo lea n(@argumcnt)**> 

wdkArgument - (Object) <xsl:value-of select-"argument"/>; 
</xsl:if> 

<xsl:value-of 8elcct-* 4 $returnVariabto"/> - (Node)executeCommand(wdkMngrName, 
wdkCmdName, request, response, document, wdkArgument); 
} 

</xsp:logic> 

<rsp:expr><xsl :value-of selea-**$return\feriable"/></xsp:expr> 
</xsl:template> 
</xsl stylesheet 



The stylesheet for the wdktags:execute contains two tern- mand name. The executeCommand method performs the 
plates. Tht first template (named command_Jieadcr) is a following steps: 

template called by the main taglibrary stylesheet to create 60 1. Creates an DCMLVisitor. It uses the default visitor 
class level methods. These methods (getCommand and provided by the XML class. 

executeCommand) are called by the code that results from 2. Uses the getcommand method to get the command 
the transformation of the wdktags:execute tags. The get- object 

Command method takes two arguments: the fully qualified 3. Invokes the execute method on the command object, 
name of a Command manager (see below) and a command 65 The created DCMLVisitor is passed to this method along 
name. It returns an I Com mand object (see below for details) with the request and argument objects that are passed to 

that is registered with the command manager by the com- the executeCommand method. 
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4. The serialized XML document produced by the visitor 
object is parsed and the resulting DOM Node is 
returned. 

The template for the execute tag performs the following 
steps: 

1. Sets up a DOM Node variable for the node generated 
by the executeCommand method. 

2. Invokes the executeCommand method with the class- 
name of the command manager, the name of the 
command and the optional argument, and assignes the 
returned Node to the Node variable set up in step 1. 

3. Adds the generated Node to the document using 
<xsp:cxpr> tags. 

ICommandManagcr 

ICommandManager is the interface implemented by indi- 
vidual command managers. It declares the following 
method: 

public ICommand getCommand(String name) throws 
Exception; 

For convenience an abstract class implementing the 
ICommand is denned. 

This class provides the following API for its subclasses: 
public void registerCommand (String name, ICommand 
command); 

Command managers can extend this class and implement 
a single method: 
public abstract void initializeMapStructure( ) throws 
Exception; 

For example, the Domain command manager that man- 
ages commands related to security domains has the follow- 
ing implementation: 



10 



IXML Visitor 
IXML Visitor declares the following methods: 

public void visit (String prefix, String tagName, String 

value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, Number 

value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, Locale 

value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, Hm- 

eZone value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, Date 

value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, URL 

value) throws XMLVisitorException; 
public void visit (String prefix, String tagname, IXMLOb- 

ject value) throws XMLVisitorException; 
public void writeOpenT^g (String prefix, String tagname) 

throws XMLVisitorException; 
public void writeCloseTag (String prefix, String tagname) 

throws XMLVisitorException; 
public void createModel (String className) throws 

XMLVisitorException; 
Visit methods are declared for most frequently used data 
types and for IXMLObject. Besides the visit methods writ- 
eOpenTag and writeCloseTag are also declared. These two 
30 methods must be used when generating nested XML ele- 
ments. For example, take the following XML document 
fragment: 



20 
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public class DomainCommandManagcr extends 
Abstract Comma ndManager 

public DomaincommandManager 0 throws Saba Exception { 
superO; 

} 

public void initial izcMapStructureO 
throws Saba Exception 

{ 

rcgistcrCommand("scarchForDomain'', new SeatchComm&ndO); 
registerCammand( M gelIX>maLiiAndPaieats*', new 
P&rentsCommandO); 

regfoteiComm&nd( u editDom&in", new EditCommandQ); 



} 



} 



ICommand 

Command objects implement the ICommand interface. 
The ICommand interface follows the Command pattern (see 
Gamma et al., 1995) and the Prototype pattern. To support 
prototyping, ICommand extends the java Cloneable inter- 
face. ICommand declares the following methods: 

public void execute (HttpServletRequest req, IXMLVisi- 
tor visitor) throws Exception; 

public void execute (HttpServletRequest req, IXMLVisi- 
tor visitor, Object arg) throws Exception 

These methods are invoked by the wdktags:execute tag in 
a model page. 

XML Serialization Framework 

Commands are used to generate an XML representation of 
some business objects. To make this task simpler, Web 
Content Server 800 introduces the notion of IXMLVisitor 
and IXMLObject following the Visitor pattern (see Gamma 
et al, 1995.). 



50 
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60 



<doc> 

<namc>A namc^/namo 

cupdated> 

<person>Jill August Vperson> 
<date>l/l /2000 </date > 

<Aipdated> 
</doc> 



A visitor can produce this document fragment with the 
following sequence of visit calls: 



visitor.writcOpenTag(null t "doc"); 
visitor. visit(null, "name", "A name"); 
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individual interconnect components installed on the inter- 

-continued connect backbone (2) the development API's (both the 

high-level and the low level interfaces) and (3) the standard 

^mA^n- protocols used to communicate between heterogeneous sys- 

visitor, visit (null, "date" abate); 5 tems. 

visitor.writcaoselag(nuii, "update"); Referring to FIG. 9, the Interconnect Backbone of the 

visitor-writeaoseTagCnuU, "doc"); preferred embodiment is shown. The Interconnect Backbone 

Note: the prefixparameter for the visit, writeOpenlag and fe ^ framework mat ^ Interconnect components. 

wnteCioscTag methods is used if the tags to generate are in some specific _ _ « , , ■ i . e -> - • 

namespace. (There is a separate namespace registration mechanism that The Interconnect Backbone provides the foundation services 

associates the prefix with a particular namespace URLI). io required by higher- level services. These foundation services 

are always present, and include services for reliable 

IXMLObiect messaging, service registration, monitoring and manage- 

The IXMLObject interface declares the following meth- ment - ^ Interconnect Backbone comprises the following 

ods: components that provide the core Interconnect services: 

15 DeliveryService 905, ServiceManager 910, Locator 915, 
and Authenticator 920. The core Interconnect services are 

always present 

- public void acceptXMLVisitor (tXMLVisitor visitor) The Interconnect Backbone' provides a framework for 

throws XMLVaitor&cepUon; registering and resolving services. Services are registered 

public String geflagName (); * , , , - . 4 , ~- JT . 

Business object that implement the DCMUObject interface can be 20 and resolved by name in an interconnect node. The Service- 
converted to XML by a command with a single method call: Manager 910 is a core service for the management of 
public void execute (HttpServletRequest req, KMLVisiior services for the Interconnect at a particular location. The 
vfeitor) throws Exception{ ServiceManager 910 tracks installed components, versions 

IXMLObiect obi - getBusmessObiecr/req); , * 0 . w M j~ 

visitor.vi5itMu4eObjcct-.obj); and system sUtus. The SemceManager 910 provides system 

} 25 management capabilities and can be queried for system 

status: which other components are present and whether they 

In the above example the getBusinessObject(req) method arc currency mmiing Components, which implement Inter- 
call stands for some business logic that's used to create the connection Services 925, are installed on the Interconnect 
business object (e.g. by using some of the business APIs). Backbone at a specific installation by being registered with 
Interconnect Server 30 me ServiceManager 910. The Locator 915 service is a 
The present invention provides a solution to the needs service component that provides a way to register and 
described above through a system and method for integral- resolve services by name. The Locator 915 services provides 
ing the disparate applications, and managing the applica- a flat registry of services at a particular interconnect loca- 
tions processes in a hardware resource and user effort tion. 

efficient manner. The automated system of the present 35 The DeliveryService 905 is a service component that 

invention uses a business systems platform comprised of insures the reliable delivery of messages. The DeliverySer- 

several unique servers to efficiently manage multiple appli- vice 905 understands the sender, the recipient and quality of 

cations which are themselves generally distributed across a service, but not the content. DeliveryService 905 works over 

network, and to control the execution of the required tasks a variety of transport protocols by using different Delivery- 

with minimum use of redundant data input to the several 40 Transports. DeliveryTransports are abstract service compo- 

applications, thereby minimizing the use of hardware nents ^ are used by me DeliveryService 905 to reliably 

resources and user input effort deliver messages over a particular set of network protocols. 

As indicated above, in a preferred embodiment the Plat- Sucfa ioco]s include database lo ^ ta51 and 
fo f m Ifltcrco^t Server allows a platform installation to Hrrp ^ messa ^ mo6tX prov ided by the DeliverySer- 
interconnecL-with-external„systems. In the preferred , 0 «_ . . r r . i. c : . . 
embedment, the Interconnect Server is a platform for infor- 45 vlce 9 f P rovides a for ^e delivery of persistent 
mation.excbange based on.XML.and sup ports man yjypes of synchronous merges using a mailbox metaphor. Inter- 
information exchlp^ac ross hetero geneo^v^ms: Su^ch connect Services 925 using the DehveryService 905 register 
heteToienebus systems could include"^nle7^risrResource themselves and are assigned an Inbox by the DehverySer- 
Planning (ERP) systems, e-mail servers, and other Saba vice 905. Subsequently, the registered service may check for 
installations. The Interconnect Server allows interconnec- 50 messages at that Inbox. The DeliveryService 905 component 
tion between such external s ystems and the Interfac e Server, is described in further detail below. 
Business_§ejveir andl nlbrmation Serve r. The Authenticator service insures that messages coming 

For example, this connection can be for purposes of into the system have the appropriate credentials. Capabilities 

importing data from ERP systems, exporting billing infor- can be associated with a particular service and users can be 

mation to accounting systems, making catalog information 55 assigned CapabilitySets. When a service is resolved, the 

available for automated-search, or allowing automated pu r- Locator 915 calls the Authenticator 920 to validate that the 

chaskg of products. The Interconnect enables collaboration requesting user has the appropriate capabilities to use the 

with the Platform network in a bi-directional fashion to service they are requesting. A Capability is created for each 

allow a Platform-enabled site to share catalog information named service in an interconnect location, for example 

with the platform network, allow the platform network to 60 "SAP/Financials/Accessor". Capabilities have names and in 

place and track orders, and to share and update learner this case the name of the capability will be the same name 

profiles. In addition, the process can be reversed: the as the service. Once created, Capabilities can then be given 

platform -enabled site can enhance their internal offering of to users who want to access the service. When a message is 

courses by i ncluding selected platform network courses in constructed, the user adds their capabilities to the message, 

their internal catalog off ering. 65 When the message is received by the target location the local 

In the preferred embodiment, the Interconnect model DeliveryService 905 validates the capabilities with the 

consists of three parts: (1) the interconnect backbone and the Authenticator 920. The Authenticator service is the genera- 
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tor of capabilities and capability keys. If a passed in capa- 
bility doesn't have the appropriate key the capability is not 
set and the authentication is rejected. The service is also used 
by other core Interconnect Services for authenticating par- 
ticular application level requests. Since a capability is a 
name-key mapping, an interconnect service can create capa- 
bilities for any purpose desired. 

Other interconnect services are implemented like the core 
Interconnect Services described above. These Interconnect 
Services register and resolve by name and respond to and 
send Interconnect messages. Services are configured and 
managed using java classes and scripts. When interconnect 
components are installed on the Interconnect Backbone, a 
site is said to be "connector enabled**. These components 
allow connections to external systems such as ERP systems 
to import, export, and synchronize data. 

Key to the Interconnect design is the separation of inter- 
face from implementation. Many of the service components 
are broken into a generic platform independent portion and 
a platform specific portion that minimizes the impact of 
changes to the implementation in the future. Most connector 
components consist of a public service component (which is 
generic) and a service sub-component (which is system 
specific). The implementation of a connector in this frame- 
work consists of providing concrete implementations for the 
service sub-components and creating XSL stylesheets that 
describe mappings between a Local Format (LF) and Inter- 
change Format (IF). Local formats are system-specific rep- 
resentations of the data supported by a service, while Inter- 
change Formats are universal representations used for 
exchange between systems. 

Referring to FIG. 9, these Connectors services may 
include Monitor 945, Accessor 935, Importer 940, and 
Updater (not shown). Accessors, Importers, and Updaters 
are essentially thin wrappers ground XSL stylesheet opera- 
tions. The v translate doc ume nts be t ween nauve fo nhats and 
the IntergJfraii&ejQnnjalj^ These 
connector services may also contain additional logic for 
cases where a single Interchange format document repre- 
sents multiple native documents, and vice versa. A more 
detailed description of the service components for these 
Connector services and their implementation on the Inter- 
connect Backbone follows. 

The Accessor 935 is a public service" component that is 
used to extract objects from the source representation and 
convert them to a Interchange Format (IF). An Accessor 935 
is configured to use a particular AccessorReader 950 to 
extract the objects from the source system and collaborate 
with Translators to perform the conversion to IF. The Acces- 
sorReader 950 is an abstract service sub-component that is 
used by an Accessor 935 to extract an object, or set of 
objects from a source system and convert them into an 
Interchange Format. Concrete implementations of the 
AccessorReader 950 are system specific and use the native 
API of the source system. 

The Importer 940 is a public service component that is 
used to import objects from Interchange Format to the target 
representation. An Importer 940 will collaborate with Trans- 
lators to perform the conversion from IF and be configured 
to use a particular ImporterWriter 960 to inject the objects 
into the target system. The ImporterWriter 960 is an abstract 
service sub-component that is used by an Importer 940 to 
convert an object, or set of objects into a Local Format (LF) 
and write them to a source system. Concrete implementa- 
tions of the ImporterWriter 960 are system specific and use 
the native API of the target system. 
^ The Monitor 945 is a public service component that 
monitors changes to local objects and reports changes to 
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interested parties in Interchange Format. Clients can register 
to receive notification of the change only, or have the 
changed object sent with the notification. A Monitor 945 is 
configured to use a particular ChangeManager 95 5 to map 
changes in the sourc e system to a standard ev ent format tha t 
the monitor can us e, lne ChangeManager 955 is an abstract 
service sub-component that is used by a Monitor 945 to map 
local events into the standard event format Concrete imple- 
mentations of the ChangeManager 955 are system specific 
and use the native API of the source system to capture 
events. 

When the Monitor 945 receives an event from the 
ChangeManager 955, it checks to see if the object needs to 
be sent with the notification. If so, the Monitor 945 will 
collaborate with the Accessor 935 and Mapper to provide the 
conversion from source object to Interchange Format. The 
Monitor 945 uses the Mapper to find the platform ID 
associated with the local identifier in the event. This plat- 
form ID is then used to request the object from the Accessor 
935. The Mapper is a utility that provides object and class 
level mapping services between representations, each con- 
nector framework contains a single instance of the Mapper. 
The Mapper data is persistent this enables the cross refer- 
ence data to survive restarts. The Mapper maintains maps for 
(1) Platform ID to Document Type, (2) Local ID to Platform 
ID, and (3) Platform (Interconnect) user to Local (mapped 
system) user. The Mapper (discussed in detail in a later 
section )converts a local object Id (a combination of Id and 
Class type ) into a Platform Object Id (POID ), POID is an 
Id that is unique across applications. POID is a serializable 
class that has URL representation 

"http:/r+hostVVmterconnect/ , '+platform+"/''+seqNo 
where host-*is the hostname of the machine on which the 
connector is running 

platform-* a parameter defined at the Saba site level. 
This parameter will make the POID unique if mul- 
tiple Saba sites are running on the same machine. 

SeqNo-*is a sequence number that that is unique for a 
host. 

Example of a POID is 

http://jade/interconnect/Saba/l this could be a represen- 
tation of local id emploOOOOOOOOOOO 1000 with class type 
com.saba.busobj.SabaEmployee. This representation can be 
converted to instance of POID by using static method in the 
POID class. 

POID class definition is 
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public class POID implements IXMLRenderable 
{ 

private GenericObjectID mLocallD; 
private URL mURL; 
private long mid; 

public POID (GenericObjectID locaUD) { 
mid - getNextId( ); 

try 
{ 

mLocallD - locaUD; 

mURL - new URL(gctURLPrefix( ) + localID.toString( ) + 
' + mid); 
} 

catch (MalformedURLExccptioa x) 

{ 

} 

} 

public void seUjocalID(GeaericObjecLlD local CD) { 
try{ 

mLocallD - locallD; 

mURL - new URL (getURLPreflx( ) + localID.toString( ) + 
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-continued 



"1" + mid); 

catch (MalformedURLException x) { 



} 



if (mid — -1) 
{ 

mid - getNcxt!d( ); 

} 

} 

public String toString( ) 
{ 

return mURL.toStriug( ); 

} 

public URL getURLQ 



return mURL; 



{ 
} 

public GenericObjectID getLocalID( ) 

{ " " " ' 



return mLocallD; 



} 

public static POID getPOID(String url) 



{ 



String temp-new String(url); 
int pos-temp JastIndexOf(**r); 
String tcmpl=tcmp.substring(pos+l); 
Long tcmp2=« Long. valueOf (tempi); 
long bash-temp2 . long\blue( ); 
POID poid=new POID( ); 
poid . mldshash; 
try{ 

poid.mURL=new URLfurl); 

} 

catch(MalformedURLException x) 

{ 

} 

return poid; 
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of the native system to capture alt the events and then pass 
these events to the monitor for further handling. The 
ChangeManagcr 955 accepts events from the native system, 
converts these events into MonitorEvent Objects, and for- 
wards these to the Monitor 945 using the method 
IChangeManager Adaptor. no tify( ) method. Once the 
Change Manager passes an event on to the Monitor 945, it 
is then the responsibility of the Monitor 945 to reliably 
deliver the request on to any subscribers who have registered 
interest. The Monitor 945 will filter out any events that are 
not subscribed to. Specifically, the Change Manager is 
responsible for (1) keeping track of all the events that take 
place in the native system, (2) creating MonitorEvent 
Objects for all events supported by the native change 
management, (3) Calling the notify method of the Monitor 
with a given event. 

ChangeManager 955 requires a reference to its owning 
Monitor 945 class to invoke its notify( ) event. It also needs 
a LocalUser object to obtain credential information. These 
references are provided during construction. 



public abstract class ChangeManagcr throws 
connectorException 

< 

public ChangeManagcr (Monitor thcMonitor, UscrObjcct 
user) 

public void shutdown( ) 



} 



30 



As mentioned above, the ChangeManager 955 coverts 
each system event into a MonitorEvent object, which it 
passes on to the monitor by calling its notify method. The 
Monitor Event class is as follows: 



Mapper stores the cross reference between the local Id 
and the POID representation of the local Id. The Mapper also 
stores cross reference between foreign POID and local Id in 
the case where the Object originated from a foreign system. 
I A Transforme r is a utility that provides translatiop.ser- 
vic es between representat ions-Using mapping data and XS L 40 
styles heets. A Tran sfor mer wra ps a particular XML parser 
ana* X SL trans lator. The Accessor calls an implementation of 
the transformer and passes the Local Format and the 
stylesheet, the transformer translates the Local Format into 
Interchange Format. 45 

Implementing a connector involves building four plat- 
form specific components and defining a set of document, 
object and user mappings. The platform specific components 
are described in detail below and include the (1) Change- 
Manager 955 (maps system events to Monitor 945 events), 50 
(2) AccessorReader 950 (extracts objects from the system in 
XML format), (3) ImporterWriter 960 (injects objects into 
the system from XML format), and (4) LocalObjectlD 
(Encapsulates the system object identifier, this is not 
required if the system can use the GenericObjectID 55 
available). Additionally, the types of documents to be 
exchanged need to be defined. Once these are determined 
and their format defined, XSL style sheets need to be written 
which convert Interchange Format to the system specific 
XML format and vice versa. 60 

At system deployment time, a number of mappings need 
to be defined. These include (1) Document type to style 
sheet, (2) local User to system user, and (3) the Translator 
the connector will use. 

The ChangeManager 955 sub-component monitors the 65 
native system for all events such as Insert/Update/Delete Q o 
objects. It can interact with the event notification mechanism 



public class MonitorEvent { 

public Object objectlD; 
public String evenfiype; 
public String docTypc; 
public Boolean applyStyieSheet; 
} 



The Monitor is responsible for implementing the interface 
IChangeManagerAdaptor which currently defines a single 
method. 



public interface IChangeManagerAdapter { 
public void notify(MonitorEvent event); 

} 



The ChangeManager.shutdown( ) method is invoked by 
the Monitor 945 and is used to gracefully disconnect the 
ChangeManager 955. When shutdown( ) is called, the 
ChangeManager 955 is responsible for closing any open 
connections, unregistering itself from the native event sys- 
tem and taking any other action required to perform a clean 
shutdown. The ChangeManager 955 can shut down itself if 
required by using this method. 

The AccessorReader 950 is a platform specific sub- 
component of the Accessor 935. It is responsible for extract- 
ing an object from the native system in a convenient XML 
representation. The representation produced must be com- 
plete enough to allow it to be transformed into the appro- 
priate document in Interchange Format. An instance of an 
AccessorReader 950 will service the requests of a particular 
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user. When an AccessorReader 950 is created a UserObject 
that identifies the system user is passed to it in its construc- 
tor. The AccessorReader 950 is responsible for making 
managing a connection to the native system on behalf of this 
user. The Accessor 935 is responsible for making sure that 
incoming requests are assigned to the appropriate Accessor- 
Reader 950 for the requesting user. The AccessorReader 
calls the Mapper to get the Platform Id (POID ) for the local 
Id representation, the local Id representation is replaced with 
the POID. 

An implementation of an AccessorReader 950 will be 
derived from the abstract class of the same name: 
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-continued 
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public abstract class AccessorReader implements 
IAccessor Reader 



15 



public interface IlmporterWriter { 

r m 

Insert the Objects from the input stream and return 
an array of native (local) identifiers for the new 
objects. The input stream is in a localized XML 
format 

V 

public Object insertObjectFromStream (Writer in) 

throws ConnectorException; 
l* m 

Insert the objects from the URL and return an array 
of native (local) identifiers for the new objects. 
The input URL is in a localized XML format, 

V 

public Object insertObjectFromURL(URL url) 

throws MalformcdURLException, ConnectorException; 
public void shutdown( ); 



} 



public Accessor Reader(UserOblject user); 



} 



public interface IAccessor Reader { 

public Reader extractObjectRcader(Object locallD) 

throws lOException, ConnectorException; 
public URL extractObj ectURL(Obj ect locallD) 
throws MalformedURLExccption, 
ConnectorException; 
public void shutdown( ); 



Specifically, the AccessorReader 950 is responsible for 
(1) Establishing a connection into the system based on the 
User Id and Credentials (2) Extracting the required object 
based on the information passed in Local Object (3) Trans- 
forming that Object into a serialized representation, which is 
an XML document (4) If the object type of the local object 
maps to more than one object in native system, then extract- 
ing all the corresponding objects in the current context, (5) 
As the objects to be transported to and from the native 
system are known, information about which objects have to 
be extracted for a given object can be maintained specifi- 



The ImporterWriter 960 is responsible for (1) Establish- 
ing a connection into the system based on the User Id and 
Credentials (2) Mapping the single XML document received 
to one or more objects required to be inserted into the native 
system (3) Converting the Native XML representation of the 
object into native system specific format (4) Based on the 
event to be performed, insert, update or delete the database 
(5) In case of a new object being inserted, remrning the local 
identifier for the object inserted (6) Providing a clean 
shutdown by closing the connection. The Importer 940 
invokes the shutdown method when it needs to shutdown the 
ImporterWriter 960. 

The UserObject encapsulates system specifigJUser infor- 
mation for an application level login (user id and password). 
35 The platform specific parts of the connector services wtfil use 
this information to log into the target system. For example 
a ChangeManager 955 may need to login to the database to 
trap the events. The Userdbject object encapsulates a string- 
based userid and the notion of Credentials. Each Platform 



30 



cally for the current implementation, (6) Serializing this ^ _ 

localObject/s into a single Local XML representation (7) j'mt.lementaTio'n nr o^id^Tte owrfTojaTDser obie "ctVlmpie 

mentations provide a subclass of the credentials Object 
customized for the security requirements of their system; in 
the simplest case the credentials are a String password. 



Returning this XML document back to the Accessor 935, (8) 
Providing a clean shutdown by closing the connection. The 
shutdown method is invoked by the Accessor 935 when it 
needs to shutdown the AccessorReader 950. 

The ImporterWriter 960 is a platform specific sub- 
component of the Importer 940. It is responsible importing 
an object into the native system from a convenient XML 
representation. The representation must be able to be pro- 
duced from a document in Interchange Format using XSL 
style sheet transformations. Like the AccessorReader 950, 
an instance of an ImporterWriter 960 will service the 
requests of a particular user. Once an Object has been 
imported the newly created local Id and the Foreign POID 
sent along with the Interchange format are inserted into the 
Mapper for subsequent use. Mapper is discussed in detail in 
a later section. 

An implementation of an ImporterWriter 960 will be 
derived from the abstract class of the same name: 



public abstract class ImporterWriter implements 
IlmporterWriter { 
Object mUser, 

public ImporterWriter (UserObject user) 
{ 

mUser ** user; 

} 
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public class UserObject implements Serializable 
{ 

String mUscrnamc; 
Object mCredentials; 

public UserObject (String username, Object credentials) 
{ 

mUsername - username; 
mCredentials - credentials; 

} 

public String getUsemame( ) 



{ 



return mUsername; 

} 

public Object getCredentials( ) 
return mCredentials; 



} 



The Lo cal object contains information about the o bject 
that the connector_u ses uniquely identif y^an^objecjln the 
65 native system. It holds the following information about the 
object (1) ID: An opaque object identifier, and (2) aClass: the 
type or class of the object. 
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The LocalObjectID class is defined as: 



public class LocalObjectID 
{ 



Object mtt); 
Object m Class; 
rablic LocalObjcctID(Objo 

mID - ID; 
mClass - aclass; 

public Object getlD( ) 

return mED; 



public Object getObjectClassC ) 



: ID, Object aOass) 



return mQass; 
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delivered from a Source site 1000 to a target SAP system 
1005 utilizing the Interconnect Server 1010 is set forth. An 
Importer component 1015 resides on the target SAP system 
and the Requestor 1020, Monitor 1025, Event Manager 
1030, Accessor 1035, and Transformer 1040 components 
reside on the Interconnect Server 1010. At step 1, At the 
Source site 1000, a Purchase order 1045 is generated and a 
"Sabalnvoice" object is created. At step 2, the Purchase 
Order 1045 is saved. Because it needs to be synchronized 
with a remote system, this triggers a pre -registered Change- 
Manager event at the EvcntManager 1030. At step 3, the 
ChangeManager passes the unique id of the Sabalnvoice to 
the Monitor 1025. At step 4, the Monitor 1025 instructs the 
Accessor 1035 to retrieve the SabaOrder in Interchange 
Format. At step 5, the Accessor 1035 retrieves the Sabaln- 
voice in serialized, canonical XML format. This is an 
internal XML format that varies for each business object. Its 
essential feature is that it contains all relevant information 
about the PO in attribute/value format. Step 5 uses a 
standard method available for all SabaObjects. 



Referring to FIG. 10, an example of the operation of the 
above Interconnect services in which a purchase order is 



The following example Local Format document is a 
sample Sabalnvoice serialized into XML: 



<?xml version-**1.0" 6tandalone-"yes"7> 
<S&baObjectSerialization xml ns :d t-*u ra :w3-o rg :xm Ida ta typcs'V 
-eSabaObject type~"coiasaba.busobj.SabaInvoice" id=" in vceOOOO 00 00000 1000" 
status=*"new"> 

<amt paid dtrtypc— "number" >0.0</amt_p aid> 

<Dther_charges dt:type="number">0.0<A)ther_cnarges> 
<acct_id 

idref-"httpy/spanugantiAnterc»nnect/Sftba^ 

<updated_by d t :type=" string' '>uone</up da ted_by > 
<balance dt:type="number">425.0</balance> 

<updatcd_on dt:type-"dateTime' V2000- 1 1 -1 0 1 9: 1 7:40. 000</updated__on> 

ocreated_by dt:typc="string">uonc</crcatcd_by> 

<created_id 

idref-**http ://spanugantiAnterconnect/Saba/com.sabainterconne<:tObjectII>@170064/6'7> 
<inv_date dt;type-"date1ime">2000-ll-10 19:17:40.000<^inv_date> 
«created_on dt:type="dateTime">2000-ll-10 19:17:40.000</created_on> 
•split dt:type-"string">domin000000000000001 </split> 
cstatus dUtypc="numbcr">100^/statu«> 

<time_stamp dt:type-"stringf'>2C10011101917399262</time_ptamp> 
<flags dt:type-"string">0O00000O0<Wflags> 

<invoice_no dt:typc="string">001000</invDicc no> 

<currency__id 

idref-"http7/6panugantiAnterconnect/Saba/com.8aba.interconnecLObjectID@14966/34'V> 
<total_cbargc3 dt:typc» M number">425.0<^total_chargc3> 
<ySabaObject> 

<SabaObject type-*com.saba.busobj.SabaInvoiceItem" id-"invit000000000001000 M 
5tatus-"new"> 

«order_item_id idref-"orditOO0OO0000001060*7> 
<invoice_id 
idref- N http://bncnraie/interconnect/Saba/^ 

<time_stamp dt:type-"string^*>2OX1110191 74061 45</time_^tamp> 
</SabaObject> 

<SabaObject type- - com.aaba.busobj.SnbaOrdcr M id-**extor000000000001040" 
status-"new"> 

<city dt:type»"string">Sunnyvale^/city> 
<addrl dt:typc-"string">Addr ll</addrl> 
<country dt:type-"stting">US</country> 
<s hipped _nmt dt:type»"number">0.0</shipped_amt> 
otate dt:type-"string">CA</state> 
^discount dt:typeo"nuinber>0.0</discount> 
<updated_by dt:type-"struig'SUO^<Aipdated,_by> 
<order_no dt:type- M string">001040>/order_no> 

<updated_on dt:type-"dateTIine">200CMl-10 19:1 3:1 9.000</updatedL_on> 
<created__by dt:type«**strLng">uone<^created_by> 
«created_id 
idref-"http://spanugantjyinterconne^^ 

<shipped_attn dt:type-"string">testl teatl </shipped_attn> 
<conlact_id 
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idrcf-"http://bnemazie/mttn»nflect^ 

<crcatcd_on dt:type-"dateTime">2000-ll-10 19:13:19.000<^crcated_on> 
<sold_by_id 

idre f-" httpy/spanuganti/interconncct/Saba/com.saba. interconnea.ObjectID@170064/6'7> 
oplit dt:typc-"8tring">domin0000 0000000 0001 </split> 
<statua dt^ypc- M numbcr">400</8tatus> 

<timc_Btamp dutype-"string>20001 11019174061 45 <#imc_stamp> 

<xompany id 

idrcf- M http;//bpanugBmi/intercom^ 

<tcrritoiy_id idrcfr-"Urri0O00O0OOO0OO00r/> 

<oconf_type dt:typc-* 4 number M >0</conf_type> 

<zip dt:type-*string">94086-</zip> 

<account_id 
idref-"httpy/spanugaMi/intercoiroed^ 

<currency id 

idref- 41 http ^/spanuganti/inteiconDCCt/Saba/com. saba. intcrconnect.ObjcctID-14966/347> 
<statns_flag dt:type-"string">2Q0G2Q0000</status_flag> 
<total_charges dt:typc-"number">425.0</total_chargcs> 
~<children> 

<SabaObjcct typc-"oom.saba.busobj.SabaOrdcrftem" id-"ordit000000000001061" 
statua-"new"> 

<order_id idref-"cxloi00000000000104Cr7> 
<uniL_cost dt:type-"numbcr">425.0</unit_cost> 
description duiype-^tring w >lnventoryl</desaription> 
<actual_qty dt:type-"number">l >/actual_qty> 
<part_id idrcf-"prdct000000000001022"/> 
<plcg_item id idrcf-"ordit000000000001061*7> 

<crcatcd_oc dtAypc="datc1unc">2000-ll-10 19:1 3:28.000 V«cated_on> 
<req qty dt:type=**Dumbci' T >l </req qty> 

<dclivcrcd_on dt:type-"dateTune">2000-ll-10 19: 17:1 3.000 </delivcrcd_on> 
<status dtAypc«"numbei">300</Status> 

<time_8tamp dttypc-"stiing">200011101917406145<^timc_jtamp> 
<CustomQ dt:tpe="string">Billed</CustomO> 
<flags dt:type-"string">0000000000</flag8> 

<total cost dtlypc»"number">425.0<Aotal_oost> 

<ilem typ dt:type-* 4 numbei' , >l </item_typ> 

<billing_statc dtaypc="numbei">101</billing_slatc> 
<SabaObject> 

<SabaObject type-"com.saba.busobj.SabaOrdcrItem" id="orditO0O00000000106O" 
6tatus-"new"> 

<order_id idrcf= - citoi000000000001040 , 7> 
<unit__cost dUtype»**tiiimbcr">0.0<Aanit_cost> 
<dcscriptioa dLtype="string">De fault Default </dcscription> 
<actual_qty dt:type-* 4 number">l <^ctual_qty> 
<part_id idrcf- a 5hpmd0000000000000017> 
<pkg_item_id idrcf-"ordit000000000001060"/> 

<crcated_on dt:type-"datelimc">2000-ll-10 19:13:27.000«/crcated_on> 
<rcq_qty dt:type"* 4 Qiimbci">l</rtq_qty> 

<dclivcrcd_on dl:typc- M datcTunc">2000-ll-10 19:17:13.000</dclivcred_on> 
<status dt:type-*'nuinber M >3Q0</status> 

<time_Btamp dt:type-"stiing">200011 1019 17406145<Aimc_stamp> 

cCustomO dt:typc-* , string*^Billcd</CustomO> 

<flags dUtype-"Btring">OOOO0OOO0OVflflgfl> 

<total_co8t dt:typc-"number">0.0<Aotal_cost> 

<itcm^_typ dt:type- M number">6</item_typ> 

<billing_5tate dt:typc-*'numbcr">101 </billing_statc> 
</SabaObjcct> 
c/childrcn> 
«/SabaObject> 

<5aba Object typc-^com.saba.buaobj.Sabalnvoiceltcm" id-"invit000000000001001" 
status-"new"> 

<ordcr_itcm_jd idref-"ordit00000000000l061'7> 
<invoice_id 

idre f- M ht tp ^/bncmazWintc rconncct/Saba/com .saba .in tc rconncctObjca[D@c82f961c/101 , 7> 
<lime_B ta mp d t: lypc-"string">2000 1 110191 7406 1 45 </time_stamp> 
VSflbaObject> 
</SabaObjectSeralizatio a> 



At step 6, the Accessor 1035 then transforms the XML 
document into an Interchange document format. The Acces- 
sor 1035 accomplishes this by passing the source document 
and an XSL stylesheet to the Transformer 1040. 

The following is a sample purchase order XSL stylesheet: 
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<?l-COPYRIGHT NOTICE Copyright (c) 1997-2000 Saba Software Inc., 2400 Bridge 
Parkway, Redwood Shores, California 94065- U 66 USA. All rights reserved.- > 
<xfll:£tyleshect xmlMml-"http^/ww.w3.orgA999/XSl/Transfonn"> 
<xsl:output oinU-xml-declaration-"iK)"indent-*'yes'* method-**xml7> 
<xsl:temp!ate matcb-"SabaObjectSerialization"> 
<S YNC_INVOICE_001 > 
<CNTROLAREA> 
<BSR> 

<VERB>SYNC</VERB> 
<NOUN>INVOICE^NOUN> 
<REVISION>001 </REVISION> 
</BSR> 
cSENDER> 
<LOGICAUD/> 
<COMPONENT/> 
cTASK/> 

<REFERENCEED/> 
<CONHRMATION/> 

<Language/> * " ' 

•cCODEPAGE/> 
<AUTHID> 

<xsl:vahie-of select- u crcatcd_by"/> 
</AUTHII>> 
</SENDER> 

<DATETIME qualificr-"CREATION T, > 
<YEAR> 

<xs):vahie-of select-" substring(//created_on, 7,4)"/ > 
</YEAR> 
<MONTH> 

<xsl:value-of select='*substring(//created_on,l > 2)"/> 
</MONTH> 
<DAY> 

<xsl:vahie-of select»"substring(//created_on,4,2)'7> 

<DAY> 

<HOUR/> 

<MINUTE/> 

<SECOND/> 

<SUBSECOND/> 

<T[MEZONE/> 
</DATETIME> 
<CNTROLAREA> 
<DATAAREA> 

<xsl: for-each select-"//SabaObject[@type- , coirLSaba.busobj.SabaIavoice , J'> 
<JNVOICE> 
<INVDATE> 

<XBl^alue-of select*7/inv_dale7> 
</INVDATE> 
«CURRENCYID> 

<3cslrvalu©-of £elect-"//currency_icV@idre f/> 
</CURRENCYID> 
<INVNO> 

ocslrvalue-of select- M //invoioe_jio"/> 
<INVNO> 
<INVOlCElD> 

<xsl:value-of select~"(S>id7> 
<tfINVOICEID> 
<0X)TALCHAROES> 

ocslrvalue-of select-7/lotal__charges7> 
</TOTAIjCHARGES> 
<ACCTID> 

<xBl:valuc-of select-"acct_Jd/@idref7> 
</ACCTID> 
<CREATEDID> 

<xsl:value-of selecU"created_id/@idref'/> 
</CREATEDID> 
<UPDATEDON> 

<xsl:value-of select-**updated_oo"/> 
</UPDATEDON> 
<ORDERID> 

<xsl:value-of select-**order_id/@idref7> 
<yORDERtD> 
<BALANCE> 

<xslrvalue-of select="balance'7> 
</BALANCE> 
<AMTPAID> 

<xsl:value-of select-"amt paid'7> 

</AMTPAID> 
<OTHERCHARGES> 

ocslrvalue-of select="other_charges7> 
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</OTHERCHARGES> 
<STATVS> 

<xs]:va)uc-of selcct-"statua"/> 
</STATUS> 
<FLAGS> 

<xslrvalue-of select- 44 flags*7> 
</FLAOS> 
<SPLTT> 

<xb lvalue- of select-" split M /> 
<S?UT> 
<POID> 

orelrvalue-of select-**poid/@idref 7> 
VPOtD> 

<REMINVDATE/> 
<REMINVTO/> 
</INVOICE> 
</xsl:fbr-eacb> 

<xsl:for-each seIcct^"//SabaObject(@type-'coin^aba.bu8obj.SabaInvoiceItem , J'> 
osalrvariablc name-"ORDERITEMID"> 

otslrvahie-of select°**order_item id/@idrcf*/> 

</xsl.-variable> 

<otsl:for-cftch selcct- - //SabaObjcct[^ypc- , com.5ab».busobj.SabaOrdcrItem , ]"> 
<xsl:if tcst»"$ORDERrTEMID@id"> 
<TTEM> 
<ACCTID> 
<xsl:value-of select» 4 7/account_Jd/@idref 7> 

</ACcnr>> 

<T0TALCOST> 

<xsl:value-of seIcct="total_cost"/> 
</T0TALCOST> 
<DESCRIPTN> 

<xslrvalue-of sel ect«" descrip tio n' 7> 
</DESCRtPTN> 
<UNITCOST> 

otsl:valuc-of sclcct*»"unit_cosf7> 
</UNITCOST> 
<ACTUAUQTY> 

<xsl:valuc-of sclcct="actuai_qty"/> 
</ACTU ALQTY> 
<LINEID> 
<xslrva]uc-of scIcct="@id"/> 
</UNEID> 

<ATTRIBUTE1> 

<xslrvaluc-of sclect="@id7> 
</ATTRIBUTEl> 

<XBl:variable name-"STUDENTID"> 

<xsl rvalue- of sclcct= M studcnt_id/@idref V> 
</xsl:variable> 

otshfor-cach select- u //SabaObject[@id-$STUDENTIDT , > 
ocslrvariablc name="STUDENTNAME w > 
<xslrvalue-of select-"l[mmc7>,<xsl:value-of 
6elect-"fname"/> ( Phone:<xEl rvalue -of selectVworkphone"/* 
</xalrvoriable> 
<ATTRIBUTE2> 
ccglrvalue-of select°"$STUDENTNAME , 7> 
<ATTR[BUTE2> 
</xsl:for-each> 
</ITEM> 
</xsl:if> 
</xsI:For*each> 
<xsl:for-cach> 

<xsl:for-each seIect« M //SabaObject(@typ&>'com.saba.busobj.SabaInvoice7'> 
<USERAREA> 
<OBJSTATUS> 

<ral:valuc-of 8clect*"@»tatus7> 
</OBJSEATUS> 
<OBJTYPE> 

<DKl:value-of select» M @type7> 
</OBJTYPE> 

<AMOUNTTJNClXIDES_TAX_J^G>N</AMOUNrr^CLUDES_TAX_Jl^G> 
<USERAREA> 
<rttsl:for-each> 
</DATAAREA> 
<SYNC_INVOICE_001 > 
</xsl:teniplate> 
<xsl:sty1csbect> 
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The following is the equivalent Interchange Format docu- 
ment generated by the stylesheet transformation, an Invoice 
in OAG BOD format. 



<SYNC_INVOICE_001 > 

<CNTROLAREA> 

<BSR> 

<VERB>SYNC</VERB> 

<NOUN>INVOICE</NOUN> 

<REVISION>00WREVISION> 

</BSR> 

<SENDER> 

<LOGICALID/> 

<COMPONENT/> 

<TASK/> 

<REFERENCEID/> 

<CONFTRMAnON/> 

<LANGUAGE/> 

<CODEPAGE/> 

<AUTHID/> 

</SENDER> 

<DATETIME qualifier- "CREATION"> 

<YEAR>1-10«/YEAR> 

<MONTH>20</MONTH> 

<DAY>0-</DAY> 

<HOUR/> 

<MINUTE/> 

<SECOND/> 

<SUBSECOND/> 

<TIMEZONE/> 

</DATETIME> 

</CNTROLAREA> 

<DATAAREA> 

<INVOICE> 

<INVDATE>2000-11-10 19:17:40.000VINVDATE> 
<CURITCNCrnD>http://spanuganti/inte 
ObjecUD@14966/34</CURRENCYID> 
<INVNO>001000</INVNO> 

<I>TVOICE[D>mvce000000 000001000 </INVOICEID> 
<TOTALCHARGES>425 .0 </TOTA1jCHARGES> 
<ACCTTD>http y/spanugaati/intcrconncct/Saba/coni.saba. interconnect 
ObjcctID@94902deb/206</AOCnD> 

<CREATEDID>http ://spanuganti/iiiterconnect/Saba/co m.saba.interconnecL 
ObjcctID@l 70064/6</CREATEDID> 
<UFDATEDON>2000-1MO 19:17:40.000<^UPDATEDON> 
<ORDERID/> 

<BA1ANCE>425.0</BALANCE> 

<AMTPAID>0.0</AMrPAID> 

<OTHERCHARGES>0.0 </OTHERCHARGES> 

<STATUS>100</STATUS> 

<FLAGS>O000000000</FLAGS> 

<SPUT>doinin000000000000001</SPLIT> 

<POID/> 

<REM[NVDATE/> 
<REMtNVlD/> 
</INVOICE> 
<ITEM> 

<ACCTII>>http://spanuganU/intero 

ObjcctID@94902deb/206VACXrnD> 

<froTALCOST>0.0</rOTALCOST> 

<DESCRIPTN>Default Default </DESCRIPTN> 

<UNrrCOST>0.0<AJNrTCOST> 

<ACrUALQTY>l </ACTU ALQTT> 

<UNEID>ordit000000000001060</LINErD> 

<ArramUTEl>ordit000000000001060^AITRIBUTEl> 

</TTEM> 

<ITEM> 

<ACXHTD>hUp://spanuganli/intercoM 

ObicctID®94902dcb/206</AOCTID> 

<fTOTALCOST>425 .0</TOTALCOST> 

<DESCRIPTN>Invcntory 1 </DESCRIPTN> 

<UNITCOST>425.0<AJNrrCOSTi> 

<ACTUALQTY>1 </ACTUALQTY> 

<UNEI D>ordit000 000000001061 </LlNEID> 

<u^TTRIBUTEl>ordkO(X)00000000106WArnUBin , El> 

</ITEM> 

<USERAREA> 

<OBJSTArUS>ncw</OBJSTATUS> 
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<OBJTYPE>com.saba.busobj\Sa bain voice </OBJTYPE> 

<AMOUNT_INCUJDES_TAX_FlJVG>N</A^ 

</USERAREA> 

</DATAAREA> 

</SYNC_INVOICE_001 > 



At step 7, the Monitor 1025 receives the Interchange 
Format document back from the Accessor 1035. At step 8, 
the Monitor 1025 instructs the Requestor 1020 to deliver the 
Invoice to the SAP system. At step 9, the Process Invoice 
document is actually delivered over the network to the SAP 
system. The Requestor 1020 reliably ensuring that the 
Invoice is actually delivered and received. At step 10, the 
Process Invoice document is inserted into the SAP system as 
a new Invoice. Step 10 is performed by the SAP Importer. 
There are several possibilities for the implementation of the 
SAP Importer, depending on the level of functionality pro- 
vided by SAP: (1) SAP supports the Interchange Document 
format directly, in which case this step is trivial, or (2) SAP 
supports a proprietary XML format, in which case a 
stylesheet can be used to transform the Invoice into SAP's 
proprietary format, or (3) SAP supports a proprietary API, 
which is used to read and process the XML document, either 
in its original format or after a stylesheet transformation into 
a more convenient format. 

As another example, an employee record maintained in an 
external system is reflected in a SABA site. An administrator 
registers a callback event with an Interconnect enabled 
human resources (HR) system. A change in the HR system 
generates an event that is captured by the external system 
Monitor. The Monitor requests the HR data from the Acces- 
sor. The external system Accessor generates the updated HR 
record as an Interchange Document. The following is 
another example Interchange Format document, a Sync 
Personnel BOD: 
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<SYNC_EMPL£)YEE_001> 

<CNTROLAREA> 

<BSR> 

<VERB>SYNC<yVERB> 

<NOUN>EMPLOYEE<^NOUN> 

<REVISION>001 </REVISION> 

</BSR> 

<SENDER> 

<LOOrCALID/> 

<componeistt/> 

<TASK/> 

<REFERENCEID/> 

<CONFIRMATION/> 

<LANGUAGE/> 

<CODEPAGE/> 

<AUTHID/> 

^/SENDER> 

<DATETIME qualificr-"CREAnON"> 

<YEAR/> 

<MONTH/> 

<DAY/> 

<HOUR/> 

<MINUTE/> 

<SECOND/> 

<SUBSECOND/> 

<TtMEZONE/> 

</DATETTME> 

</CNTROLAREA> 

<DATAAREA> 

<S YNC__EMP LOYEE> 

<EMPLOYEE> 
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35 



<NAME index-" 1">MR.</N AM E> 
<NAME mdcx-"2">tc3tfiist</NAME> 
<NAME index="3">testlast</NAME> 
15 <EMPIX>YEETO>hltpV/bncinazie/u»terconnect/Saba/com.sabainter 
conn ect,ObjectID@ 170 179/680 5 </EMPLO YE E[D> 

<EMPLOYEETYPE >Pcnnancnt</EMPLOYEETYPE> 
<SYNCIND/> 
<DUN5NUMBER/> 
<ADDRESS> 
<ADDRLINE index= _ 17> 
<ADDRLINE index- "27> 

<city/> 

<COUNTRY/> 
<POSTALCODE/> 
<STATEPROVN/> 
<TELEPHONEl/> 
<TELEPHONE2/> 
<FAXl/> 
<PAPENlTD/> 
<EMAlL/> 
^/ADDRESS 
<NAME2/> 
<CURRENCY/> 
<DESCRIPTN/> 
</EMPLOYEE> 
<USERAREA> 
<MNAME/> 
<TERRITORYI D/> 
<COMPANYID/> 

<STARTEDON>2000-07-24 00:00:00.0<VSTARTEDON> 
<TERMINATEDON/> 

<LOCATIONID>http ://bnemazic/interconnect/Saba;com.saba.intcr 
connccLObjcctfD@cd92/6801</LOCAnONID> 
<RATE/> 

<SSNO>llM3-2222«/SSNO> 
<GENDER>0</GENDER> 
<SHORTDESCR[PTN/> 
<JOBTYPEID/> 
<MANAGERID/> 
<QUOTA/> 

<UPDATEDON>provide<AJPDATEDON> 
<UPDATEDBY>provide</UPDATEDBY> 
<MAXDISCOUNT/> 
<HOMEDOMAIN/> 

<USERNAME> 1093-202 </USERNAME> 
<FLAGS>0</FLAGS> 
<PASSWORD/> 

<STATUS>Full Tune</STATUS> 
<LOCALEID/> 

<EM PLO YEENO> 1 85 </EMPLOYEENO> 
<SPUT/> 

<CREATEDON>provide<yCREATEDON> 
<OBJTYPE/> 

<OBJSTATUS>new</OBJSTATUS> 
<DEStREDJOBTYPEI Of > 
</USERAREA> 
</SYNC_EMPLOYEE> 
</DATAAREA> 
</SYNC_EMPLOYEE__001> 
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The Monitor then receives the BOD from the Accessor 
and instructs the external system Requestor to deliver the 
personnel change to the SABA system. The Requestor then 
65 delivers the Sync Personnel document over the network to 
the SABA system. The SABA Updater receives the Sync 
Personnel document. It uses an XSL stylesheet to transform 
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the document into tbe canonical format used internally. The 
following is an example XSL personnel stylesheet: 



<xsl stylesheet 
xmlns 3tsl-"http ://www.w3 .org/1 999/XSL/Transform "> 

<!-COPYRIOHT NOTICE Copyright (c) 1997-2000 Saba 
Software Inc., 2400 Bridge 

Parkway, Redwood Shores, California 94065-1166 USA. All 
rights reserved. -> 

<xsl:oatput indent-' yea "method-"xml"omit-xinl- 
dedaiation-"no7> 

<xal:template match-"* |T> 

<isl : apply- templa lts/> 
</xsl:template> 

<xsl:template matcbVtext () | @*"> 

<xsl:vahie-of select-'. "/> 
</xsl template> 
. . <xsktemplate match-"SYNC_EMPLOYEE_001"> 
<xsl:for-each select- 7" > 

<SabaObjectSerialization xmlns :dt- "urn w3- 
orgrxmldatatypcs " > 

<SabaObject> 
<xsl:attributc 

name-" type ">com.saba.busobj.SabaEmpIoyee</xsl^ttribute> 
<xsl:attribuie name-'status"> 

ocslrvalue-of 
select- VAJSERAREA/OBJSTATUS 7> 

<xsl:if test-VAJSERAREA/OBJSTATUS-' ' 7> 
</xsl:attribute> 
<xsl attribute name="id"> 

<xsl:value-of select-7/EMPLOYEEID7> 

<xsl:if test- 7/EMPL0YEEID-' ' 7> 
</xsl:attribute> 

■ctitle dt:type- "string" dt:size="10"> 

<xsl:value-of select- 7/N AM E{1] 7> 
<titlc> 

<fname dt:type— "string" dt:size='25"> 
«Blrvalue-of sclcct-7/NAME [2] 7> 
<xsl:if test-7/NAME[2>" 1 7> 

</£namc> 

<lname dtitype- "string" dt:size="25"> 
<xs):value-of select-7/NANE[3] '/> 
<xsl:if test-7/NAME|3)- , ' 7> 

</lname> 

<mname dtuype="string" dt:size«"25"> 

<xsl:value-of select-7/USERAREA/MNAME7> 
</mname> 

<homephone dtrtype-" string" dt:eize— "25"> 
oolrvalue-of select- 7/TELEPHONE1 7> 
</homephone> 

<workphone dtitypc- "string" dt:sizc*25'> 

«cal:value-of select-7/TELEPHONE27> 
</workphonc> 

<fax dt:type-*string" dt:size"25"> 
<xsl:value-of sclect-"//FAX17> 
</£ax> 

<created_on dt:type- "airing" updateFlag-"No"> 
<xsl:&Uribute 
name-"provide" >true</xal :attribute> 
</created_on> 

<created_by dtrtypc- "string" updateFlag-"No"> 
ocsl:at tribute 
name- "pro vide" >true</xBl:attribute> 
</crcatcd by> 

<updated_by dfctype- "string "> 
<xsl attribute 
name-" provide' >true</xsl:attxibuie> 
<Aipdated by> 

<updated_on dt:type-"dateTime"> 
<xsl:attributc 
name-"provide">true</xsl:attribule> 
</updatcd_on> 
<temtory_jd> 

<xsl:attribute name-"idref , > 
ocslrvalue-of 
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select- 7/USERAREATERRlT0RYID'/> 
</xsl:attribute> 
</territory_id> 
<custom0 dt:type"string"> 
<xsl:vahie-of 
select-7/USERAREA/CUSTOM07> 
</custom0> 

ccustoml dt:type-"string"> 
<X8l:varue-of 
select-7AJSERAREA/CUST0M 1 7> 
</customl> 

<custom2 d t: type-" string "> 
<xsl:varuc-of 
select- 7/USERAREA/CUSTOM27> 
</custom2> 

<xustom3 dt: type— "string"? 
<xslrvahie-of 
select~7/USERAREA/CUSTOM37> 
</custom3> 

<custom4 dutype»"string"> 
<xslrvarue~of 
select-"/AJSERAREA/CUSTOM47> 
</custom4> 

< company id> 

<xsl:attribute name— "tdreP'> 
<xsl:varue-of 
select- 7AJSERAREA/COMPANYID"/> 
<xal:if 

t£St=7/USERAREA/COMPANYII>' ' ">bisut000000000 000001 </xsl: if > 
</xsl:attribute> 
</compaQy_id> 

<addrl dtrtype— "string" dfcsize-"80"> 

<xslrvahie-of select=7/ADDRLTNE[l J"y> 
</addrl> 

<addr2 dtitype-'string" dt:size-"S0"> 

<Kl:varue-of select-7/ADDRLINE[2] 7> 
</addr2> 

<city dt:type="string" dt:size-"50"> 

<xsl:valuc-of setect-"//CTry"/> 
</city> 

<state dt:type-" string' dt:size-'50"> 
<xslrvalue-of 
selcct>-7/ADDRESS/STATEPROVN7> 

</state> 

<zip dtrtype-" string" dt:size—"80"> 

<xsl:value-of select-7/POSTALCODE7> 
</zip> 

<counlry dt:type-"string" dt:size»"80"> 
<xsl:vahjo-of select-"//COUNTRY"/> 
</ccuntry> 

<email dt:type— "stricg"> 

<xxl:value-of select- 7/EMAIL7> 
</email> 

<employee_no dt:typc«"5tring"updatcFlag-"No" 

dt size-"80"> 

<xsl:valuc-of sclect-"//EMPLOYEENO'/> 
<xsl:if test-'tfEMPLOYEENCV ' "/> 

<Vemployce_no> 

<s talus dt :type-"number"> 

<xsl:valuo-of select-7/USERAREA/STATUS7> 
<xsl:if test-7/USERAREA/STATUS-' ' ">Full 

Timc^/xsHf> 

</status> 

<password dt:type-'string" updateFlag-"No"> 
<xsl:value-of 
select-"/AJSERAREA/PASSWORD7> 
<xsl:if 

tesU7/USERAREA/PASSWORD-' ' ">412ABF98CDF3EF99</xsl:if> 
</password> 

<usemame dt:type-"string" update Flag-" No"> 
<xslrvahie-of 
select»7/USERAREA/USERNAME7> 
</username> 

cmanager id> 

<xsl attribute name-'idrer> 
<xsl:vatue»of 
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select-7/USERAREA/MANAGERID7> 
</xsl:attribute> 

</manager__id> 

<emp_typc> 
<xslr«luc-of sclcct-7/EMPLOYEETYPE7> 
<ral:if lest-7/EMPLOYEETYPE-' ' "/> 

</cmp_typc> 

<started_on dt:type-"dateTime"> 
<xs):value-of 
select- 7/USERAREA/STAKTEDON7> 
</started_on> 

<terminated_on dt:type-"dateTunc"> 
<xsl:va]uc-of 
sclect-7/USERAREA/TERMINArEDON7> 
</terminated_on> 
<iocation_id> 
<xsl:attribute name-'idref^ 
<xsl:va!ue-of 

scl<xt^7AJSEIUREA/lXCAriONiD"/> " 
<!- Change value for default 

location id — > 

<xsl:if 

tcst-7/USERAREA/LOCAnONn>' ' ■>locat0O0O0OOOC001000</xsl:Lf> 
</xsl:attr£bate> 
^location id> 

<max_dis count dtuype- "number "> 
<xsl:value-of 
select- 7/USERAREA/MAXDISCOUNT-/> 
<xsl:if 

test-7/USERAREA/MAXDISCOUNT=" ' '>0</xsl:if> 
</max_discount> 
<split dtrtype- "string "> 

<xsl:value-of select=7AJSERAREA/SPUT7> 

<xsl:if 

test-7/USERAREA/SPUT-' ' "xiominOOOOOOOOOOOOOO 1 </xsl :if> 
■c/split> 

•crate dfctype— "number "> 
<xsl:valuc-of selcct="/AJSERAREA/RATE7> 
<xsl:if 

test-7/USERAREA/RATE-' ' ">0</xsl:if> 
</ratc> 

<quola dtlype="number*> 

<xsl:value-of select-7/USERAREA;QUOTA7> 
<xsl:if 

test=7/USERAREA/QUOTA=' ' ">0</xsl:if> 
</quota> 
<jobtype_id> 
<xsl attribute name-'idref^ 
<xslrvalue-of 
5clec>7/USERAREA/IOBTYPEID7> 
</xsl:auribute> 
</jobtype_id> 

<m no dt:type-"string"> 

<xsl:value-of select-7/USERAREA/SSN07> 
<xsl:if test- '/AJSERAR EA/SSNO"' * 7> 
</ss_no> 

<gender dt:type-"number"> 
<xsl:value-of select-7/USERAREA/GENDER7> 
<xsl:if test-*/AJSERAREA/GENDER-' ' "/> 
</gender> 
<home_domain> 
<xs1:aUxibute name-'idreF > 
<xsl:value-of 
select-7/USERAKEA/H0MED0MAIN7> 
<xsl:if 

test-7/USERAREA/HOMEDOMAIN-* ' "/xlominOOOO 00 00000 
0001</xsl:if> 

</xfil:attribute> 
</homc_do main> 
<des ire d_job_type_id> 
<xsl attribute name-"idref > 
<xst:value-of 
select-7/USERAREA/DESIREDJOBTyPEID"/> 
</bcsl:attribute> 
</dcsired_job_tvpe_id> 
<locale_id> 

<ral attribute name-"idreF> 
<xsl:vaIue-of 



select-'WSERAREA/LOCALEID7> 
oal:if 

5 test-7/USERAREA/LOCALEID-' ' ">local000000000000001Vxsl:if> 

</xsl:atiributc> 
</locale_Jd> 
<flags dt:type- B 6tring M > 

oal:valuc-of sclcct-7/USERAKEA/FLAGS7> 

<xsl:if 

10 test-7/USERAREA/FLAGS-' ' ">OO0O000O00</xsl:U> 
</flags> 
<timezcne_id> 
<xsl attribute name-'idreF> 
otslrvahic-of sclcct-7/TIMEZONE7> 
<!- Change value for default 

!5 timezone_id --> 

<xsl:if 

test-7/nMEZONE-* ">tzone000000000000008</xfil:if> 
</xsl aUributo 

</timczonc id> 

</SabaObject> 
</SabaObjectSerial izatk>n> 
</xsl:for-each> 
</xsl:template> 
</jtsl styles heet> 
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The following is the equivalent Local Format document, 
a generated Saba Person in Saba Canonical Format: 



<SabaObjectSerialization xtnlns:dt-"urnrw3-org:xinldatatypes"> 
30 <SabaObject type-"com^aba.busobj^abaEmployee" 
status»*ensting M 

id= " http ://b oe mazie/interconn ect/ Saba/co m. saba . inte rconnecL Object 
ID@170179/6805"> 

<utlc dttype -"string" dt»izc-"10">MR.</Utle> 

•efname dt:type=" string" dtsize="25">testfirst</&iaine> 
35 <lname dt:type— "string" dt:size-'25">testlast</lname> 

<mnamc dt:typc="string" dt:sizc-"257> 

-ehomephone dtrtype- "string" dtsize-"25">972 580 
7645</homephone> 

ororkphonc dt:type="string' dt:sizx='25 n f> 

<fax dt:type-'string" dt:size-"257> 
^ <updated_by dt:type-"string" provide-"tnie"/> 

<updated_on dt:type="datcTimc" provide- "true 7> 

<terrilory id idref-" "/> 

<custom0 dt:type-"string"/> 

<customl dt:type-"string"/> 

<custom2 dt:type="string7> 

<custom3 dt:type-"string"/> 
45 <cuatom4 dt:type-"string7> 

<company_id idref-"bisut0000000000000017> 

<addrl dt:type-' string" dt:gize-"80">1213 addrl 1234</addrl> 

<addr2 dt:type-' string" dt:size-"807> 

<city dt:type-"string" dt»ize-"50"> Irving </city> 

<state dt:type-" string" dt:size-"50">TX</state> 
50 <zip dt: type- "string" dt:size-"80">75038</zip> 

<country dt: type- "string" dt:size-'80">US</country> 

<email dt:type-"string"/> 

<employee_no dt:type-" string" dt:size-"80">185</employee_no> 
<status dt:type-'number">Full Hme</status> 
<password dtnype-"string">412ABF98CDF3EF , 99</password> 
55 <useraame dt:type-"8Uing*>1093-202<Aisername> 
<manager_id idrefc" "/> 
<emp__type >Pennanent </emp_type> 
<started_on dt:tvpe-"datcTimo">2000-07-24 
00 :00;00.0</startcd_oQ> 

< terminated on dt:type— "dateTirne'/> 

<location_id 
idrcf-"http://bncmazic/mtcrconne^^ 
ectID@cd92/680r/> 

<max__discount dt:type-" number" >0</max_dificount> 

<aplit dt:type-'sUing">domin000000000000003Vsplit> 

<rate dL-type=" number" >0</rate> 

<quota dt:type-' number ">0<7quota> 

<jobtypc_id namc-"idref*/> 

<ss_no dt:type="string'>lll-ll-2222</ss_no> 
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<gcndcr dt:type='nuinber">0</gender> 
<home_domain idrcf-"domin000000000000001"/> 
<dcsircd_4ob_type__id idrcf-* "/> 
<lccalc_id idref--local0000000000000017> 
<flags dt:type-"string">0</nag?> 
<timczonc_id idref-"tzone0000000000000087> 
</SabaObjcct> 
</SabaObjectSeriaIization> 



A SabaEmployee object is instantiated based on the 
canonical XML document. This object is then saved, com- 
mitting any changes to the database. 

The set of interconnect components is extensible so 
additional functionality can be added over time. Adding a 
Searcher component allows a site to be "exchange 
enabled" — able to share catalog (or other) information with 
other sites. In this way users can get results from searches 
that combine remote catalog offerings with local catalog 
offerings. Adding a Purchaser component makes a site 
"eCommerce enabled" — able to offer products for sale via 
an automated interface. This enables learners who choose 
classes from a catalog that has been shared on SabaNet to 
purchase them via SabaNet. A Versioner component could 
offer the ability to automatically upgrade to the latest version 
of the software or to automatically purchase a license 
extension via a Licensor component. 

As described above the DeliveryService is a key compo- 
nent of the InterconnectBackbone. Interconnect messages 
follow an persistent asynchronous protocol. Messages are 
sent and received with a message payload. Message pay- 
loads are opaque to the DeliveryService, any object may be 
sent as a message payload. A message recipient may reply to 
a message by constructing a reply message from the original 
message and sending that reply as a separate asynchronous 
message. 

Message senders and recipients are responsible for syn- 
chronizing their own messages. There are message ID fields 
in the Message that may be used for this purpose. A Message 
contains (1) The sender's InterconnectAddress (2) The 
recipient's InterconnectAddress (3) The sender's credentials 
(4) AmessagelD (5) AreplylD (6) The message payload (an 
Object). Message senders and recipients have an Intercon- 
nectAddress. This Address is managed by the DeliverySer- 
vice and contains (1) An Inbox identifier (InboxID) assigned 
by the local DeliveryService (2) A String in URI format 
identifying the service (mServiceURI), (3) An Object iden- 
tifying the associated User (mUscr). 

The InboxID is used by a DeliveryService for local 
message routing. The URI identifies the specific software 
component and is used to determine whether the Intercon- 
nectAddress is local or remote. To send a message, an 
Interconnect client must: (1) construct a Message for the 
given sender and recipient, (2) add the message payload to 
the message, (3) set the message ID or the reply ID if 
needed, (4) send the message using the DeliveryService's 
I Postman interface. If the message is local it will be deliv- 
ered using the InboxID. If it is remote it will be forwarded 
to the appropriate remote DeliveryService for delivery at 
that location. 

In order to use the DehveryService, a connect must first 
be made. Upon connection the DeliveryService assigns an 
InboxID that is used internally for message routing and 
synchronization. This InboxID is used in subsequent calls to 
the DeliveryService. 

Once connected, messages may be sent or received from 
the DehveryService. There are two ways messages can be 
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delivered depending upon how the recipient registers. The 
recipient may Poll for messages using 
IPostman.getMessage( ) or handle incoming messages by 
implementing IRecipient.recieveMessage( ). The 

5 IPostman.oonnect( ) method has an optional I Recipient 
parameter. If a valid IRecipient is passed, incoming mes- 
sages will be delivered using that interface. In this case, 
behind the scenes, an InboxAssistant is created in a separate 
thread to watch the Inbox on behalf of the recipient. When 
a message is sent using IPostman.sendMessage( ) the Deliv- 
eryService is responsible for making sure that the message 
gets delivered to the appropriate Inbox. If it cannot it must 
report or log an error. 

In the simple case where a message recipient is in the 
same installation as the sender, the DeliveryService will put 

1 the message in the recipient's Inbox and be done with it. The 
message will stay there until the recipient or the InboxAs- 
istant takes it out. When finished using the service, an 
Interconnect client may disconnect from or release the 
Inbox. Disconnecting tells the DeliveryService to maintain 
messages as the recipient intends to reconnect at some later 
time. Releasing frees all DeliveryService resources associ- 
ated with the Inbox. 

When the DeliveryService determines that message is 
destined for a recipient in another Interconnect location, the 

25 local DeliveryService must forward the message to its peer 
DeliveryService at that location. The service identifier in the 
message's recipient address is used to determine whether the 
recipient is local or remote. Tnis identifier is a URI with the 

3Q Host name (as returned by InetAddress.getLocalHost( 
)).getHostName( )) and Interconnect service name. For 
example, a service named "SabaAccessor" running on Saba 
host "flamenco" would have an URI of the form "rmi:// 
flamenco.saba.com/SabaWeb/Saba/Accessor". 

The ServiceManager will look at the serviceURI and 
determine whether the service in remote or local, if it is 
remote it will resolve the address with it's remote peer. 

Key to the design of the Interconnect is the notion of 
pluggable transport protocols. To accommodate this, the 
Delivery Service has 2 components (1) Delivery Service (2) 
Persistent Message Manager. The Delivery Service writes 
messages to outbound queues (if the message needs to be 
delivered to an external system), the Persistent Message 
Manager polls out bound queues to deliver the message to 
the host the message is intended for. The persistent Message 
Manager has the uses pluggable transport protocol. For 
implementing a protocol using RMI a class needs to be 
written implementing IPMTransport. The Persistent Mes- 
sage Manager (PMM ) acts as the listener for receiving 
messages. Messages received are put into inbound queues, 
the Delivery Service delivers messages from the inbound 
queues to the Subscribers. 

The rationale behind this separation is to allow for the 
Interconnect DeliveryService/PMM to be deployed across a 

55 wide variety of communication protocols. Supporting a new 
protocol requires building a delivery transport that wraps 
that protocol. The protocol wrappers are implemented as 
peers, and initiate and accept connections, send and receive 
messages, terminate gracefully, etc. For example, the fol- 

fio lowing steps would be performed to build a TCP/IP socket 
Interconnect Transport: 

1. Implement a interconnect listener/accepter 

2. Implement a client connection initiator 

3. marshal and write interconnect messages onto a socket 
65 4. read and unmarshal interconnect messages from a 

socket 

5. implement the IPMTransport interface 
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A discussion of mapping Ids from one system to another 
using the POID concept follows. When the Accessor 
receives a request to export an object to a stream, it is passed 
a user object and a platform ID (POID). In this case the 
POID is an ID associated with the local object in this system. 
Generally this ID will be acquired from another exported 
document or as a result of a Monitor event however, some 
initial mappings may need to be provided to bootstrap the 
system. 

Given the POID, the Accessor looks up the local ID and 
the document type in the Mapper. It is an error if there is no 
associated local object. The Accessor then uses the docu- 
ment type to look up the appropriate stylesheet, transformer 
and XMLHelper to use during the accessing and transfor- 
mation steps. 

Using the AccessorReader for the configured system, the 
local object is extracted into a stream in a system specific 
XML format. The XML stream, the stylesheet and an output 
stream are then passed to the transformer that writes the 
transformed XML to the new stream. The transformed 
stream is then returned 

This is in the simple case where the XML to export 
contains no external references to objects in the source 
system which are not contained in the generated XML In 
the more complicated case, the XML stream is not fully self 
contained, i.e. it contains references to objects that are not 
part of the XML stream. XML however may contain the 
local Object Id of this Object, this Id is meaning less outside 
this system. This Id needs to be replaced with its POID. 

The Accessor service needs to attempt to insure that all 
unresolved references in the outbound XML document are 
represented in the form of a POID. During export, the 
Accessor must find or create a POID for each reference 
encountered and fix up those object references in the XML 
stream. The Accessor will use the Mapper to determine if the 
referenced object has an associated POID. If a POID does 
not exist, one will be created and added to the Mapper's 
tables. 

Step by step on the Accessor side: 

1. The Accessor requests a document be exported by 
invoking the Accessor method: 

Reader IAccessor.getObjectReader(UserObject user, 
POID poid) 

2. The Accessor looks up the local object ID from the 
Mapper: 

LocalObjectID Mapper.getLocaUD(POID platformID) 
If there is no local ID an exception is raised. 

3. The Accessor looks up the document type from the 
Mapper: 

String Mapper. getDocumenfltype (POID platformID) 
If there is no document type, a default is used for the 
configured AccessorReader. 

4. The Accessor looks up the stylesheet, IXMLHclper and 
ITransformer using the docType. 

5. The Accessor requests the object in XML format from 
the AccessorReader: 

Reader I AccessorReader. extractObjectReader( 
LocalObjectID locallD, IXMLHelper helper) 

6. The Accessor fixes up ID references in the XML 
stream. It scans the stream looking for foreign POIDs. 

7. When a reference ID is encountered by the Accessor, it 
resolves it to the POID using the Mapper. If no POID 
exists one is created. The POID is written to the XML 
stream. 

8. An output stream is created and the document is 
transformed: 

void ITransformer.transfonn(String stylesheet, Reader 
in, Writer out) 
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When the Importer receives a request to import an object 
from a stream, it is passed the stream, a user object, the 
document type and a platform ID (POID). This POID is a 
foreign ID, created when the document is exported from the 
source system. 

The XML stream, a stylesheet and an output stream are 
passed to the transformer and a new XML stream is pro- 
duced. This new stream is passed to a platform specific 
object that inserts it into the system. On insert, a local object 
ID is created by the system and returned. 

When the local ID is returned to the Importer, the 
Importer asks the Mapper to map the foreign POID to the 
Local Object The POID is then returned to the requestor in 
the import status reply. 

This is in the simple case where the XML to import 
contains no external references to objects in the source 
system which are not resolved in the XML. 

In the more complicated case, the XML document not 
fully self contained. The document to import contains ref- 
erences to objects that are not part of the XML document. 
The import service attempts to resolve these references to 
insure the referential integrity of the object being imported. 
During the transformation phase, the Importer must resolve 
the foreign references to local objects and fix up those object 
references in the XML stream. 

The specified object may have already been imported in 
which case there will be an entry in the local Mapper's 
foreign POID map. The Importer asks the mapper to resolve 
the POID to a local object. If this object has been mapped, 
a string representation of the Object ID is used to replace the 
foreign POID in the XML document. 

Id the case where the object has not been previously 
imported the importer has two choices. Either it can fail and 
report an error, or it can attempt to pull the object from the 
foreign system. It is reasonable to make this a configurable 
option and perhaps only support error reporting in the initial 
release. , 

Step by step Id mapping on Import: 

1. The Subscriber requests a document be imported by 
invoking the I Importer method: 

ImportStatus IImporter.importObjectFromStream( 
POID poid, UserObject user, Reader stream, String 
dociype) 

2. The Importer looks up the stylesheet, IXMLHelper and 
ITransformer using the doctype. 

3. An output stream is created and the document is 
transformed: 

void ITransformer. transform(String stylesheet, Reader 
in, Writer out) 

4. The Importer fixes up foreign ID references in the XML 
stream. It scans the stream looking for foreign POIDs. 

5. When a foreign ID is encountered by the Importer, it 
resolves it to the local ID using its Mapper. The local 
ID is written to the XML stream. 
LocalObjectID Mapper.resolveForeignObject(POID 

foreignID) 

6. The fixed-up XML stream is passed to the Importer- 
Writer to insert into the system. 
LocalObjectID insertObjectFromStream(Reader in, 

IXMLHelper helper) 

7. Map the new local ID to the original foreign POID 
passed with the import request. 

void Mapper.mapForeignObject(POID foreignID, 
LocalObjectID locallD) 
So far the discussion has been around the Interconnect/ 
Connector framework. The following discusses Connector 
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Specific plug ins, and defines the specific components for can locate and deliver a wide variety of resources, from web 

each connector. Taking Saba Connector as an example: pages to Business Objects. Information Distributor 1201 

a. SabaChangeManager— This class extends the Change also supports a wide variety of descriptive information 
Manager, starts a thread that polls the database for required by business applications, from standard web meta- 
cbanges. Once a change is detected the change is 5 data to catalog information to skills and competencies, 
passed over to the Monitor for further processing. This Information Distributor 1201 also supports a broad van- 
class has the specific logic to poll Saba database. ety of information sources, match conditions, and delivery 

b. SabalmporterWriter-This class extends the Importer- mechanisms 1202. Information Distributor 1201 generates 

Writer and has the logic to import Objects in Local ™"*es ™* a 7™* o£ ^^^.f^ * 
r * /P «r v . c iT ♦ variety of options for delivering match results, 

format (SCF)into Saba system. 10 J^^q^^ 

c. SabaAccessorReader— This class extends the Acces- fa ^ A developer of ordinary skill in the art 
sorReader and has the specific logic to retrieve objects can write queries a combination of Java code and 
from Saba system in local format. S q L j D k provides equivalent functionality using a higher- 

Every new connector has to implement these 3 classes to j cvc j languages for representing and querying data and 

work with application connecting. Extending this we have 15 simpler programming APIs. Information Distributor 1201 

sapChangeManager, saphnporterWriter and sapAccessor- a iso leverages open standards 1206 by supporting industry 

Reader. standards such as RDF and XML. Support for industry 

"" Ihformatiori'Server * standards helps ensure the availability of third-party tools 

The present invention relates to a novel information that interoperate with IDK and increases the set of data and 

distributor method and apparatus. The present invention can 20 information on which IDK can act. 

provide services for consolidating, analyzing, and delivering In an embodiment of the invention, Information Distribu- 

information that is personalized, relevant, and needed. tor 1201 can determine if a new software developer has just 

It employs metadata-based profiles to match information joined a new project. If one of the skills required for the new 

with users. User profiles may include skill competencies and software developer's new assignment is knowledge of 

gaps, roles and responsibilities, interests and career goals. 25 XML, then upon joining the project, Information Distributor 

The Platform services provides the interface and infra- 1201 automatically send an email to the new software 

structure for building agents that work in concert to decide developer containing information about the company's stan- 

what information is delivered, when it is delivered, and how dard "Introduction to XML" course, 

it is delivered. In an embodiment of the invention, Information Distribu- 

The platform services integrate with the Platform Inter— 30 tor 1201 can keep a development manager informed about 

connect Server to wori ^acros^ifferent networks _and_dis- J the status of the other development groups in his division. As 

pa rate"~mformation systems. This allows u sers to receive \ part of his custom home page provided by the corporate 

mformatio n^from a variety of sources and'locations via a I portal, he can view a list of the most recent updates 

single, consisten t inter face. — ' submitted by each development manager, and call up each 

The present invention uses an Information Distributor 35 report in his web browser. 

Developer's Kit (IDK) to be used by software application In an embodiment of the invention, Information Distribu- 

developers of ordinary skill in the art. tor 1201 can detect when an affiliated training provider.has 

The platform of the present invention identifies and fills made available a new advanced class in Java. Information 

information gaps across the corporate value chain. IDK Distributor 1201 sends email to all advanced and expert Java 

provides the infrastructure and core functionality to find and 40 programmers in the company announcing the availability of 

deliver relevant and targeted information. In an this class. 

embodiment, the IDK enables more sophisticated querying In an embodiment of the invention, Information Distribu- 

and matching functionality than in the prior art and serves as tor 1201 can detect when the HR department institutes a new 

the technology underpinnings for a stand-alone Enterprise approval practice for all new hires. Information Distributor 

Information Portal (EIP) solution. 45 1201 assures all hiring managers in the company receive a 

For more information on RDF, refer to the W3C home new entry in the Corporate Information channel that 

page, incorporated by reference in its entirety, at the URL explains the policy change. 

www.w3.org/RDF/ and formal specification located at URL If an updated price list for a region is generated, Infor- 

www.w3.org/TR/REC-rdf-syntax/. mation Distributor 1201 sends an email containing the new 

The above sources of information are incorporated by 50 price information to all dealers in that region, 

reference in their entireties. If an employee has a change in his family status, such as 

FIG. 11 shows a structural overview of an IDK 1100 of the if the employee has a baby, the next time the employee views 

present invention. IDK 1100 is associated with a language the HR department's benefits page in his web browser, the 

1102, such as RDF, for representing web metadata, a lan- Information Distributor assures customized plan and deduct- 

guage for querying web metadata, and a set of APIs 1104 for 55 ible information appears that is appropriate for his new 

defining information services based on what data is used, family status. 

when and how a match is performed, and what is done with Referring again to FIG. 11, in an embodiment, the Infor- 

the results. mation Distributor adopts a new standard for web metadata 

FIG. 12 shows a functional overview of an Information and its definition of a high-level language 1102 for querying 

Distributor 1201 of the present invention. IDK 1100 can 60 this metadata. 

annotate and match broad resources 1200, support diverse Metadata is structured information about information, and 

sources, conditions, and delivery options 1202, provide an is used to identify, categorize, and locate resources of 

easy migration path 1204, and leverage open standards interest. Resource Description Format (RDF) is a new, 

1206. XML-based standard for associating arbitrary metadata with 

In an embodiment of the invention, Information Distribu- 65 any web resource. It can be used to describe resources 

tor 1201 provides a flexible mechanism for annotating and ranging from a course catalog on the WWW to a business 

matching web resources 1200. Information Distributor 1201 object representing a client. 
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In an embodiment a language used to query web metadata 
1102 may be RDF Query Language (RQL), an XML-based 
query language for writing queries against RDF data. It can 
represent both simple and complex queries, and can also 
accommodate metadata matching, where a metadata 
description can be part of the query. For example, this allows 
a particular employee's complete skills gap— expressed as 
an RDF description — to be used in a query to locate classes 
that fill the gap. 

FIG. 13 shows an exemplary view of APIs 1104 associ- 
ated with the Information Distributor In an embodiment, the 
Information Distributor partitions information matching and 
delivery issues into three areas, each addressed by a distinct 
type of agent, Import Agents 1300, Match Agents 1302, and 
Delivery Agents 1304. The combination of Import Agent 
1300, Match Agents 1302, and Delivery Agents 1304 is a 
novel combination of the present invention. 

Import Agents 1300 create and import the RDF descrip- 
tions used by IDK. Import Agents 1300 can generate meta- 
data from a variety of sources, from existing web pages and 
business objects to content management systems to enter- 
prise applications. 

Match Agents 1302 determine what matches and queries 
occur under what conditions. Match Agents 1302 can be 
triggered by a request to a web or application server, by 
specific events, or on a regularly scheduled basis. A Match 
Agent 1302 also specifies the RQL and any input metadata 
to use as the metadata query. 

Delivery Agents 1304 dispatch the results of a query or 
match. In an embodiment, Delivery Agents 1304 integrate 
with a variety of delivery mechanisms, from web page 
generation and XML datagrams to email and event messag- 
ing systems. 

In an embodiment of the invention, FIG. 14 shows an 
exemplary view of using Information Distributor or IDK 
1100. A software developer of ordinary skill in the art can 
use IDK to query objects 1400 or to implement custom 
delivery service 1402. In an embodiment, Query Objects 
1400 may be used similarly to today's finder methods, that 
is, a high-level mechanism to query SABA business objects, 
but using and requiring knowledge of RDF and RQL. 

FIG. 15 shows an exemplary overview of Query Objects 
1400. The invention, through a user associated with the 
invention, such as but not limited to a software developer of 
ordinary skill in the art, defines RDF Metadata Mappings 
1500 for the objects and metadata of interest. Then, the 
invention Authors An Import Agent 1502 to capture this 
metadata. The invention may then Author An RQL Docu- 
ment 1504 to query this metadata and author a Match Agent 
to Perform the Query 1506 and a Delivery Agent to act on 
the query results. 

FIG. 16 shows an exemplary overview of Implement 
Custom Delivery Service 1402. The invention, through a 
user, such as but not limited to a software developer of 
ordinary skill in the art, may use the invention's IDK to 
novelly Implement a Custom Information Delivery Service 
1402, using RDF, RQL, and the full IDK interface. In an 
embodiment, the invention Defines RDF Metadata Map- 
pings 1600 for the objects and metadata of interest. The 
invention Authors An Import Agent 1601 to capture this 
metadata. The system and method of the present invention 
then Authors An RQL Document 1602 to query this meta- 
data. The invention then Authors a Match Agent 1604 to 
perform the query, and Authors a Delivery Agent 1606 to 
dispatch the query results. The invention then Integrates All 
Agents 1608, including the import agent, the match agent, 
and the delivery agent, into the existing system. 
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In an embodiment of the invention, Information Distribu- 
tor (IDK) is a Software Development Kit delivered as part 
of Platform 4.0. It provides the infrastructure and basic 
functionality needed to build and customize the Enterprise 

5 Information Portal. 

IDK provides the infrastructure and services to perform 
metadata-based queries. Unlike traditional text-based search 
engines, in an embodiment the IDK operates solely on 
descriptive data about resources, rather than the resources 

io themselves. 

In an exemplary embodiment of the invention, referring 
again to FIG. 13, IDK defines interfaces for metadata 
generation (Importers or Import Agents 1300) and matching 
(Resolvers or Match Agents 1302) and for delivering query 

15 results (Dispatchers or Delivery Agents 1304). Combina- 
tions of these three services allow the Information Distribu- 
tor to interoperatc with a variety of enterprise systems and 
to service queries in a broad range of applicatiori 'dbmains. 
In an embodiment, a portal server may be delivered using 

20 IDK. 

Import Agents are responsible for consolidating a variety 
of information sources. Importers integrate with various 
external systems, analyze the descriptive data about specific 
resources in the system, and import this data into a custom 
25 RDF database. Exemplary information sources include 
internal email systems and Intranets, SABA EMS, ERP 
systems, and the World Wide Web. 

Common tasks supported by Import Agents include: 

Executing batch imports 
30 Scheduling imports at regular intervals 

Analyzing and translating metadata formats 

Specifying a target database 

Integrating with SABA Interconnect 
35 Match Agents are responsible for matching between infor- 
mation resources and user profiles. Match Agents execute at 
regular intervals or in response to specific requests. They 
perform intelligent comparisons between metadata descrip- 
tions of imported resources and user profiles. These com- 
4Q parisons return a set of information resources as the match 
result. 

Because they act on detailed user profiles, Match Agents 
can finction as personal agents, identifying those resources 
most relevant to a user's job, interests, or objectives. For 

45 example, they can determine that a user requires knowledge 
of a specific technology for a new job assignment, and 
deliver suggestions for classes covering that technology. 

Because they match against categorized metadata, 
Resolvers can return more accurate and meaningful results 

50 than is possible with traditional text-based searches. For 
example, Match Agents can return only documents that have 
been updated within the last week. Or they can distinguish 
between articles about an individual and articles written by 
the individual. 

55 Delivery Agents are responsible for delivering the results 
of a match to the correct recipients in the appropriate 
fashion. Delivery Agents integrate with various delivery 
mechanisms, delivering either pointers to the match results 
or the actual information itself. Typical delivery vehicles 
60 include e-mail, web servers, and enterprise portals. 

Common tasks supported by Delivery Agents include: 
Delivering results immediately upon availability 
Delivering results at delayed or batched intervals 
Integrating with SABA Interconnect 
65 In an embodiment, the final system and method of the 
present invention may be capable of scaling to handle 
enterprise-wide document databases. An initial prototype 
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that may be delivered is capable of demonstrating the 
proof-of-concept without exhibiting the scalability of the 
final system. 

The IDK provides a flexible mechanism for describing 
and comparing a wide variety of resources. The actual data 
being compared may vary widely among applications, rang- 
ing from competencies and skills for gap analysis to docu- 
ment summaries and reviews for web content. Yet the actual 
operations involved in determining a match tend towards a 
small set, text and numeric comparisons and basic Boolean 
logic. Thus, the IDK needs to casts a broad variety of 
properties into a consistent format for purposes of compari- 
son. 

In an embodiment, the invention employs the Resource 
Description Format (RDF), the World Wide Web Consor- 
tium's standard for web metadata. It meets the above 
requirements because it is designed to support a wide range 
of different applications, expressing them all in a consistent 
attribute property/value format The format also allows the 
definition of standard vocabularies for specific application 
domains, and the mixing and matching of these vocabularies 
to describe a resource. The format has a web-centric design, 
employing URLs to describe any form of web resource and 
XML to serialize its data graphs and is seeing slow but 
steady adoption in a variety of domains, from electronic 
documents and on-line learning to news stories and business 
cards. 

By choosing RDF as the Information Distributor's stan- 
dard metadata format, the invention makes it easy and 
efficient for customers to work with the system because they 
can turn to external sources for training and documentation, 
can use third party tools for defining their metadata, and are 
more likely to already have or be able to find developers 
familiar with RDF. Furthermore, as RDF is used for more 
domains, the Information Distributor can be applied to an 
ever-increasing amount of content. 

RDF is essentially a model for representing attribute/ 
value pairs as a directed labeled graph. It consists of 
statements that pair a web resource (anything identified by 
a URL) with a property and a value. At its core, IDK 
provides a flexible mechanism for comparing these attribute/ 
value pairs and taking action upon the comparison results. 

The Match Agent operates by comparing one RDF 
description to the full set of RDF descriptions in a specified 
database. Because of the variety and flexibility of RDF 
descriptions, additional instructions are required to specify 
how the match is performed. This is the function of the 
match template. 

Match templates specify certain fields as belonging to a 
target RDF file. In an embodiment, the target is a file that is 
provided along with the match template to customize the 
search, for example, to perform a predefined search against 
a specific individual's description. Match templates may 
also be written to perform a fixed search, in which case there 
is no target RDF file. Merging a match template with a target 
RDF file produces an RDF query. 

Match templates can specify the following aspects of a 
query: 

The specific properties to be compared. 
The comparison operation (-, !-, <,>) 
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Boolean operators (AND, OR, NOT) 
A set of comparison functions, including: 
like (text matching) 
latest (most recent date) 
container operation: contains, first, etc. 
In an embodiment, match templates are: 
easy to create and edit by hand 
conducive to creation by an authoring tool 
1Q easy to parse 

In an embodiment, the complete syntax and specification 
used by match templates is defined by the RDF Query 
Language Specification, described below. 

RDF-based Match Templates are unique and never before 
15 contemplated by the prior art. The combination of a match 
template and a target RDF file can produce an RDF Query. 
In an embodiment of the invention, the core of the Infor- 
mation-Distributor is a RDF Query engine that performs a 
query on one or more RDF databases, then returns a set of 
20 resources that satisfy the query. 

In an embodiment of the invention, a client may use the 
Information Distributor SDK by performing the following 
exemplary method steps: 

1. Write an Import Agent that implements the 
25 ImportAgent interface and employs the MR. 

importRDF( ) method 

2. Write a Match Agent that implements the Matchagent 
interface and employs the MR. match( ) method. 

3. Write a Delivery Agent that implements the Delivery- 
30 Agent interface. 

4. Create a new instance of an MR (Metadata Repository). 

5. Write code to create specific instances of the above 
agents and set them into motion. 

35 In an embodiment of the invention, an ImportAgent is 
responsible for delivering metadata in RDF format to a 
Metadata Repository. Specific Import Agents may interface 
with a particular source of metadata, translate that metadata 
into RDF, and use the MR.importRDF( ) method to import 

^ that RDF. Import Agents may register with the Event Man- 
ager to perform imports in response to particular events. In 
an embodiment, the ImportAgent has the sole responsibility 
for performing the metadata translation. In an embodiment 
of the invention, the invention provides utility routines that 
assist with translating various common metadata formats or 

45 serve to automatically generate metadata. In an embodiment, 
the invention provides additional utility functions for inter- 
facing with the Event Manager or scheduling batch imports. 

In an embodiment of the invention, a Match Agent is 
responsible for performing a metadata match. Specific 

50 Match Agents may create a Match Descriptor and pass it to 
a specific MR to perform a match. Match Agents may 
perform matches in response to particular events. In an 
embodiment of the invention, distributed queries may be 
performed across multiple MR. 

55 Match Agents may employ a utility class called Match- 
Descriptor that captures all information needed for a meta- 
data query or match template. 
This class is defined as follows: 



public class MatchDescriptor 
{ 

/•• MatchDescriptor constructor. 

* @param aTemplate Contents of a match template. 

* ©param aTarget URt of a target RDF file. May be NULL Lf the 
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-continued 



match 

" template describes a fixed search. 

* @param a Handler Match Handler to operate on the match results. 

V 

public Match Descriptor (String alemplate, String aTarget, 
MatchHandler aHandler) 

}/* MatchDescriptox */ 



In an embodiment of the invention, a Delivery Agent is 
responsible for delivering the result of a metadata match. 
Delivery Agents implement the following Java interface: 



15 



20 



public interface Delivery Agent 

/** Deliver the results of a match. 

" @param mrs A MatchResultSet containing the match 

results. 

* ©exception Delivery Exception Thrown when 
delivery fails. 
V 

public void deliver (MatchRcsultSet mrs) throws 
Delivery Exception; 

} /* DeliveryAgent 7 



Delivery Agents use a utility class called MatchResultSet 
that contains the result of a metadata match. A MatchResult- 
Set contains a Vector of RDFResource objects, a class 
containing a URI for each resource returned by a metadata 
match, as well as additional, optional properties. The 
MatchResultSet class is defined as follows: 



* </Description> 

* </resultset> 
+ 

In an embodiment of the invention, a MR (Metadata 
Repository) is an interface that any Metadata Repository 
' must implement. 

The following is the interface for a MR: 



public class MatchResultSet 
{ 



r m 

* Set the results. 

* @param theRcsults Vector of RDFDescription objects. 
V 

public void setResults( Vector the Results) 

r m 

* Return an Enumeration of match results. 

* ©return Enumeration of RDFDescription objects 
7 

public Enumeration getResults() 



public interface MR 

/" The import methods are used to insert RDF 
25 metadata into the MR. */ 

/" Import an RDF document specified in a URL 

* @param uri URI to the RDF file. 

* ©exception ImportException Thrown when import 

fails. 

V 

public void importRDF (String uri) throws 
ImportException; 

/** Import an RDF document specified in a Reader. 
* 

* The "key-parameter serves as a unique 

identifier, 

35 * when RDF is re-imported with the same key value, 

it replaces the previous 

* import. The "key "value is most typically the 

URI. 

* @param r Reader containing RDF text. 

* @param key Unique identifier for this RDF 



40 



source, 
fails. 



■ ©exception ImportException Thrown when import 



45 



Id an embodiment of the invention, the contents of the 
MatchResultSet may be serialized as a simple XML docu- 
ment. One RDF Description element may be associated with 
each result. Using RDF permits the invention to deliver 
additional properties that may be useful to the consumer of 
the MatchResultSet, such as properties taken from the 
source RDF Description or additional properties returned by 
the Match Engine. 

The following is pseudocode for a sample XML result: 



50 



55 



* <resultset> 

* description about«>"http://sabainet/devo/status/sbll_ 
12_99.htmr> 

* <dc:Title>Weekly Status of Project Sweet Baboo</ 60 
dc:Title> 

4 </Description> 

* description about-" http://sabainet/devo/status/Ipll__ 
08_99.html M > 

* <dc:Title>Weekly Status of Project Beelhoven</ 
dc:Title> 



65 



V 

public void importRDF(Reader r, String key) throws 
ImportException; 

/•* Perform a metadata match. This involves the 
following steps: 

* <ol> 

* <li> Extracting the contents of the 
MatchDescriptor 

* <li>Gcnc rating a MatchResultSet 

* <li>Passing the MatchResultSet to the 
MatchHandler contained 

* in the MatchDescriptor 

* </ol> 

* @param md MatchDescriptor fully describing the 
match to perform. 

* ©exception Match Except ion Thrown when match 

fails. 

V 

public abstract void match (MatchDescriptor md) 
throws Mate hExccp Lion; 
/•* 

* Retrieve a named property of a specific 
resource. Returns null if 

* the specified property does not exist. 

* @param resource URI of resource. 

* ©param namespace URI of namespace; null if no 
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A Property/Value/Operation triple can also contain a 
-continued nested Condition; this allows querying against reified 

statements, or statements about statements. Refer to Query 



namespace is specified. H for an example. 

• @param property Property name. A^j, Or, Not 

• ©return Property value. ^ operators perform logical operations on one 
public string getProperty(string resource, String or more conditions. Not negates the value of a single 

namespace, String property) throws Match Exception; conditions, while And and Or perform logical operations on 

} /• MR */ two or more conditions. 

' Because many RQL operations operate on containers, 

10 there is an " applies" attribute that determines the behavior of 

In an embodiment of the invention, RDF Query Language grouping operators on containers. When "applies-within" 

(RQL) is an easy-to-learn, easy-to-author language for que- (the default), operations within a grouping condition must 

rying collections of RDF documents. It is designed to apply to the same value within a container. For example, this 

support the full functionality required by Information Dis- allows specifying conditions on two elements within the 

tribute r. 15 same container element. When "applics-across" conditions 

RQL is an XML application. An RQL document may need not apply to the same value in the container, 

consist of a single Select element containing a single Con- Notice that the Not operator returns all resources that do 

dition. A condition may be either a direct operation on a not satisfy the specified condition, which is not the same as 

single property, or a Boolean grouping operation, which can resources that satisfy the negation of the condition. Refer to 

in turn contain further Conditions. RQL can define a number 20 Q uerv 3 f or an example of this distinction, 

of built-in comparison operations; it also allows compari- Property 

sons against variables extracted from an accompanying The Property element identifies a specific, named prop- 
target RDF file. ert y Q f a Resource. Its contents identify the named property 
Each Element is described in detail below. ( a iso known as the predicate). Its contents can be a nested 
RDFQuery 25 property, that is, multiple property names separated by 
RDFQuery. is the root element of an RQL document It J slasbcs . ^ s ^ tax may navi g atc over multiple 
must contain a single Select element. properties, where each property value is a resource with its 

Ac^nZer is a grouping property value. Containers can ^ Pf°P ert ^; ™? * ™* b * RDF 

be Bags, unordered Usts of resound or literals, Sequences, „ <W "P*th" attribute for nested queries, 

ordered lists of resources of literals, or Alternatives, distinct As a convenience, it may not be necessary to specify 

choices. Container-related properties as part of the path, that is, Bag, 

Literal Sec l> Alt, and li elements are automatically navigated past 

A literal is a property value that is a simple string Value 

(including possibly XML markup) or other primitive The Value element defines the value against which a 

datatype. 35 specific property is compared. It can contain a literal string, 

Property which is compared directly against literal properties, or 

A property is a specific characteristic or attribute used to against a container property using one of the container 

describe a resource. The RDF model may contain operations. 

Statements, which are a named property and value assigned \ Q a Match Template, the Value element may also contain 

to a specific resource. 40 a Variable element, which indicates that the value is 

Resource extracted from the target RDF file. The Value element can 

Aresource may be anything described by an RDF expres- also specify a dtdtype attribute that specifies the datatype of 

sion. A resource is identified by a URI. me value. The only datatype that must be explicitly specified 

Select is "dateTime" which indicates that a date comparison is to 

The Select element defines the properties that are returned 45 bc pcr f 0 rmed on a ISO 8601 date. Date values can also 

by an RDF Query. The result of an RDF Query is itself an incorporate the "'sysdate" keyword to indicate an operation 

RDF document; it is the set of RDF Description elements based on the current date. Refer to Query 12 for an example, 

that satisfy the query. By default, only the Resource URI is Operation 

returned (as an about, aboutEach, or aboutEachPrefix Operation element defines how the comparison is 
attribute of the Description element). The properties 50 performed. RQL supports a number of predefined opera- 
attribute is used to define additional properties to be tions. 

returned. It is a space-separated list of all property names to Literal operations operate on literal values. They include: 

be returned. The initial implementation only aUows literal, equals w performs an exact text match or numeric 

first-level property values to be returned; that is, containers, comparison. It will also match a resource URI. 

nested properties and resources are not supported. 55 ^ } ^ fof m u 

Within the Information Distributor, the returned RDF / v , \ . J ' 

elements are wrapped in a MatchResultSet object for con- greaterThan (>) performs the numeric comparison, 

venient manipulation from Java. lcssThan <<) ^ dotms thc numcnc comparison. 

Condition greaterThanOrEquals (>«) performs the numeric com- 

The Condition element defines a condition that RDF 60 parison. 

Descriptions must satisfy to be returned. Conditions are lessThanOrEquals (<=) performs the numeric compari- 

either simple, in which case they specify a Property/Value/ son. 

Operation triple, or complex, in which case they contain one like performs a substring text match, 

of the boolean operators. The simple Conditions simply We provide verbose forms of the various arithmetic 

obtain a property and compare it to the value using the 65 operations for readability; this is because characters such as 

specified operation. Operations are defined for literal prop- <require escaping within XML, which can become 

erties and container properties. unwieldy. 
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Container operations operate on container values (Bags, 
Sequences, and Alternatives). They include: 
contains 
first 
last 

index(n) 
sum 
count 

Notice that the first, last, and indexo operations are only 
meaningfil for Sequences. 

Multiple Operations can be specified in a single Condi- 
tion; this is useful for queries that combine container and 
literal operations, such as a numeric comparison on the first 
entry of a Sequence. There are also two implicit shortcuts: 

1. A literal operation on a container first performs an 
implicit "contains." • • • • ■ - - 

2. A container operation without a further literal operation 
always performs an implicit "equals." 

Variable 

The Variable element defines a substitution variable. It 
contains a Property element, and is used to obtain a literal 
value from a target RDF file. 

Variable elements are only found in Match Template. 

Namespaces 

RQL supports namespace declarations as attributes of any 
element. It then applies these namespaces to property values. 
This means that property values can use namespaces pre- 
fixes. See the examples section for several illustrations of 30 
this technique. Notice also that this is an uncommon use of 
namespaces; rather than applying namespace declarations to 
element and attribute names, it is applied to the text within 
the document. 

Notice also that for variables, the corresponding 35 
namespace declarations must exist in the target RDF file, as 
opposed to the RQL file itself. 
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Document Type Definition (DTD) for RQL Documents 

compared. It is either a constant String, or a 

Variable whose value comes from e target RDF file. 
— > 

<! ELEMENT value (#PCDATA | variable)' > 
<t~ The value element can have a dtitype attribute 

specifying its datatype --> 

<!ATTUST value dtrtype NMTOKEN «MPLIED> 

<!— A variable inrfiratwi a property value obtained from a 

target RDF file; it contains a Property element. -> 

<1 ELEMENT variable (property)> 



25 



Document Type Definition (DTD) for RQL Documents 

<I- An RQL document contains a single Select element --> 

<! ELEMENT rdf query (select> 

<!— Each Select clause contains a single Condition. 

The "properties" attribute defines the information to 
return as part of the result set. 

Note that the URI of each matching Resource is always 
returned. — > 

<! ELEMENT select (condition)> 

<!ATTLIST select properties NMTOKENS «MPUED> 

<I~ A Condition can either directly contain an operation, 
or contain a boolean grouping operator --> 

<)ELEMENT condition ( (operation*., property, value, 
condition?) | and | or | not)> 

<I~ Boolean grouping operators --> 

<lELEMENTand (condition, condition+) > 

<1— the "applies" attribute determines whether or not the 
condition within a grouping operation must 

all apply to the same value in a Collection. --> 

<IATTLIST and applies (within | across) "within"* 

<t ELEMENT or (condition, condition*) > 

<!ATTLIST or applies (within | across) "within"* 

<! ELEMENT not (condition) > 

<!— An operation defines how to compare a property to a 
value — > 

<IELEMENT operation (# PCDATA) > 
<!- Property identifies a specific property in an RDF file. 
For container objects, any children are acceptable 
matches, and intervening Container and Description tags are 
automatically navigated past --> 

<! ELEMENT property (#PCDATA)> 

<!— A value defines the value to which a property is 
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The following are exemplary embodiments of RQL docu- 
ments. The example queries may all use the following 
source RDF document: 



<7xml version- '1.0'?> 

<rdf:RDF xmlns:rdf- "http://www, w3.org/1999/02/22-rdf-syntax- 

nsr 

xmlns:hT«"htrp7/www.saba.conVhr#" 

xmlns xwp-'http^/wwwjabaxom/cwp*' 

xmlns :ems="http y/www.sabaxx)m/ems#" 

xmliisrvCard-"rittp^/imc.ois/vCard/3.0#"> 
<idf: Description 
about="http ^/www.sabacom/people/sally_brown "> 
<vCard:N rdf rpars eType» " Resou rce" > 

<vCard:Family>Brown</vCard:Family> 

oCard:Gfven>Sally</vCard:Given> 

</vCard:N> 

<vCard:UID>987-65-4320VvCard:UID> 
<vCard:ROLE>Managcr</vCard;ROLE> 
<vCard.ORG rdfparseType-" Resource" > 

<vCard:Oigname>Development</vcard:Qrgname> 
</vCard:ORG> 

<hr:Location>HO</hr:Location> 
<hr:Reports> 
<rd£Bag> 
<rd£li 

resource-"http ^/www.saba.com/people/Snoopy'/> 
<rd£H 

resource»"htrp y/www.saba.com/people/Woodstock"/> 
</rdf:Bag> 
</hr:Rcports> 
<ewp:competency> 
<rd£Bag> 

<rd£li>Java.ExperWrdf:li> 
<rd£ li>XML. Proflcient</rdf :li> 
</rdf:Bag> 
</ewp:compctency> 
<ewp:Icterests> 
<rdf:Bag> 

<rdf: li>Java</rdf :li> 
<rdf:li>EJB</rdf:li> 
<rd£li>COM</rdf:li> 
</rd£Bag> 
</ewp:Interests> 
<e ms:Training_Locations> 
<rd£Seq> 
<rd£Ii>San Francisco, CA</rdf:li> 
<rd£li>San Jose, CA</rdf:li> 
<rd£li>Los Angeles, CA-</rdf:li> 
<rd£li>Denver, CO</rdf:li> 
</rdf:Seq> 
</ems :Training_Locations> 
</rd£Description> 
<rdf: Description 

about-"http:/www.Baba .co m/people/sal ly b rown " bagID- ' ID001 " > 

<cwp:compctency>EJB.Advanced<g f cwp:compctcDcy> 
</rdf:Description> 

<rdf:Description aboutEach-'#ID001"> 
<ewp:attained>1999-02-25<^cwp:attained> 
<ewp:provider 
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rdf: resource- " hup ://www.sabanet/Al lAbou Java/"/> 
<xwp:details> 

<rdf:Bag> 5 
<rdf:li>CBT</rd£li> 
<rdf:li>evaluotion</rdfJi> 
</rdf:Bag> 
</ewp:details> 
</rdf:Description> 

</rdf:RDF> 10 



The following exemplary query ("Query 1") associated 
with the above source RDF document selects all managers 
in a department: 



<rdfquery> 

<select properties- *\Card:FNAME vCardORG" 
xmlns.^<^-"hUp^/imc.oigM>rd/3.0#** 
xmlns :hr-" http://www.saba. com/hr#"> 
<condition> 
<not> 

<condition> 

<operation>equa Is </ope ratio n> 
<property>hr:Lc<»tion-</property> 
<va!ue>HQ</value> 
<condition> 
<^not> 
<Vcondition> 
</select> 
^/rdfquery> 



<?xml version-" 1.0"?> 
<!DOCTYPE rdfquery SYSTEM "rqLdtd"> 
<rdfquery> 
<select> 
ccondition 

iinlosrvCa nl-~http-JAnxi.org/vCardy3. O^S 
<operation>equab </operatio n> 
property >vCard:ROLE</propcrty> 
cvalue>Manager<A r alue> 
</condition> 
</sclect> 
</rdfquery> 



The following exemplary query ("Query 2")selects all 
developers in a department, or everyone in a development 
organization: 



The following exemplary . query ("Query 5") finds an 
employee named "Sally Brown": 
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<7iml version-" 1.0"?> 
<!DOCTYPE rdfquery SYSTEM "iqUtd"> 
<idfquery> 
<select> 
^condition 

xmlas:vCard="http://imc.org/VCard/3.0#"> 
<operation>equals</operatinn> 
<prc>perty>vCard:ORG/vCard:ORGNAME<</property> 
<valuc> Development Vvaluo 
</oondition> 
</select> 
<7rd6query> 



35 



The following exemplary query ("Query 3") selects the 
name and division of everyone who is not located at a 
headquarter location: 



<?xml version-"1.0"?> 
<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 
<rdfquery> 

<select propertic5-"vCaid:FNAME vCard:ORG" 
rmlnsM3ard-"hnp:/Ainc.orgA<^ud/3.0#'' 
xmlns Ar-"http^/www.saba.com/hr#"> 
<condition> 
<operatioa >notEquals </operation> 
<property>hr:Location</property> 
<valuc>HQVvaluc> 
<fcoadition> 
</selcct> 
<^rdfquery> 



The following exemplary query ("Query 4") returns slightly 65 
different results, in that it also returns all resources that do 
not have an hn Location property: 



<7xml version-"1.0"?> 
<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 
<rdfiquery> 

<select xmliBn<^ard= M httpy/imc.org/vCard/3.0# >, > 
<oondition> 
<and applies*»"within"> 
<condition> 

<operation>equals</operation> 
<property>vCard :N/vCard:Family <^operty> 
<varue>Brown</value> 
<condition> 
<condition> 

coperat ion >equa Is </ope ratio n> 
<property >vCard :N/vCard:Given<^property> 
<vahioSally</value> 
</condition> 
</and> 
<condition> 
</select> 
</rdfquery> 



40 The following exemplary query ("Query 6") selects 
everyone with a competency of "Advanced" in EJB: 



<?xml vereion-"1.0"7> 
4 * <!DOCTYPE rdfquery SYSTEM *rql.dtd"> 
<rdfquery> 
<select> 

<condition milnsxwp-^http^/www.soba.coin/ewp^^ 
<operatio n>co ntains</operatio n> 
<p i ope rty >ewp:Cbmpetency </property> 
50 <™lue>EJ B.Ad vanced</vnlue> 

</condiiioo> 
■^select > 
</rdfquery> 



The following exemplary query ("Query 7") selects 
everyone who will train in San Francisco: 



<?xml version-" ].0"?> 
<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 
<rdfquery> 
<select> 

<co adit ion xmlns:cms-"http^/www.sab^com/cmsM' , > 

<operatio n>co mains </opera tion> 

<p rope rty >c ins :Tra Lain g_JLocatio ns </propcrty> 

-cvahjoSan Francisco, CA</valuc> 
</condition> 
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-continued 



</sclcct> 
</rdfquery> 



The following exemplary query ("Query 8") selects 
everyone will train in some location in California and return 
to that location: 



<propeity>hr:Reports</prope ity > 
o/ahje>2</value> 
<y conditio a> 
</sclect 
</rdfquery> 
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<?iml vcision-"1.0"?> 
<!DOCTYPE rdfquery SYSTEM **rqLdtd"> 
<rdfqucry> 

<sclcct p^opc^tics="cms:T^lining__Locations' , 
xmlnsxms-*'http^/www^abaxomycms#''> 
<coudition> 

<opcration>likc</opcration> 
^roperty^msfnaining_JLorations</propeity> 
<value>CA</vaIuo 
</ccndilion> 
</selcct> 
</rdfquery> 

The following exemplary query ("Query 9") selects 
everyone whose first choice of training location is anywhere 
in California: 



The following exemplary query ("Query 12") finds all 
who have an advanced competency rating in EJB, with the 
competency ratings obtained from evaluations. 



15 <?xml version&"1.0"?> 

<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 
<idfqucry> 

<sclcct xmlns:cwp-"htDp7/wwvv.saba.com/cwp^'> 
<condition> 

<operation>cquals</operBtion> 
20 <qjropcrty>cwp:compctcncy<ypropcrty> 
<vahie>EJB. Advanced </value> 
condition > 

<opcration >con tains </opcradon> 
<property>ewp:details</pioperty> 
<value>evaluation Rvalue > 
</condition> 
</conditiorx> 
</selcct> 
</rdfquery> 



<?iml vereum="l.(T?> 
<!DOCTYPE rdfquery SYSTEM ~rql.dtd"> 
<rdfquery> 

<selcct properu'es="cms:Training_Lcx»tions'* 
xmlns :ems«"http ;/Avww.saba.com/ems#*'> 
<condition> 

<operatton>iadex (1) </opcration> 

<operation>like</opcration> 35 
<propcrty>eins:Trainiiig_JLocations-^)roperty> 
<valuc >CA</valuc> 
</condition> 
</select> 
<^rdfquery> 



The following exemplary query ("Query 10") finds the 
manager of an employee named "Woodstock": 



30 The following exemplary query (" Query 1 3") finds every- 
one hired in the past month: 



<?xml vcreion="a.0"?> 

<!DOCTYPE rdfquery SYSTEM "http;//dlipkin/rqLdtd"> 
<idfquery> 

<selecl xmlns: hr="http ://www.saba.corn/hr#" 
xmlns :dt-"urn :w3-org:xmldatatypes"> 
<condition> 

<operation>gicalcrThan</opcratioa> 
<property>hr StartDate property > 
<varuc dt:type-"datcTimc M >sysdatc-3Wvaluc> 
</condition> 
</select> 
</rdfqucry> 
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<?xml vereion-"1.0"7> 
<IDOCTYPE rdfquery SYSTEM <4 rql.dtd"> 
<rdfqucry> 
<select> 

<condition xmln3:hr-"http^/wwwjaba.oom/hr#"> 
<opcration>contains</opcration> 
<property>h r :Reports</property> 
<vahie>http ://www.»aba.co m/people/Woodstock <fvahxc> 
</condition> 
</select> 
</rdfquery> 

The following exemplary query ("Query 11") finds all 
who have more than two direct reports: 
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<?xml veision-"1.0**?> 
<!DOCTYPE rdfquery SYSTEM *rql.dtd"> 
•crdfiqucry> 
<sclect> 

<condition xmlns: hr-"hUp ^Avww.saba.cam/hi#"> 
<operation >count</operatio n> 
<operation>greaterThan</operatioii> 
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Information Distributor Implementation 

The following is an exemplary implementation embodi- 
ment of Info Distributor in the platform of the invention. The 
implementation has two components: 

1. DatabaseMR — a Java class that implements a Metadata 
Repository (MR) oo top of a relational database. This 
class provides utility methods to be invoked by Import 
Agents, Match Agents, and Delivery Agents. 

2. RQL parser — a Java class that implements the RQL 
query language. It parses an RQL document and 
executes the query using the DatabaseMR. 

In an embodiment, DatabaseMR implements the MR 
interface, that is, it provides the ability to import an RDF 
document, return the value of an RDF property, and perform 
a metadata match. 

DatabaseMR uses a database schema containing the fol- 
lowing tables: 

MR_sources — contains URI references to each imported 
document 
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Column 


Datatype 


Description 


id 


number 


Primary key 


source_URI 


varchar2(1024) 


URI of imported document 



MR_triples_base — stores the actual data of all RDF jq 
triples from imported RDF documents. 



Column 


Datatype 


Description 


uri_jef 


number 


Foreign key to M Resources 






table 


rdL_property - 


■•■varchar2(1024) 


Property values *-* 


rdf_resource 


varchar2(1024) 


Resource values 


rdf_object 


varcnar2(1024) 


Object values 
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Id addition, there is a view called MR_triples defined as 

CREATE VIEW MR_triples AS (SELECT rdf_j>roperty, 

rdLrcsource, rdf_object FROM MR_triples base) 25 
This view allows other data sources to also be manipu- 
lated by the MR, as described below. 
As an example, the following RDF document: 

30 



<7xml version="1.0"?> 

<rd£RDF xmlns:rdf-"http:/Aeww.w3.org/l 999/0 2/22-rdf-syntax- 

ns#" 

xmlnsxJo-^UpV/purl.org/dc/eleinents/l.ir 
xmlns :schedule="http://www.£aba.co m/RDF/schedulc/1.0#"> 35 
<rd£ Description resource=*http^/dlipkin/classl"> 
cdc:title>HTML Fundamentals </dc:title> 
<schedule:startDate>1998-12-07</scheduleatartDate> 
</rdf:Dcscription> 
</rdf:RDP> 

40 

appears as the following data: 



private void generatTriples (Reader u String key) throws 
ImportException 

r - (Reader) new RDPReader(r); 
InputSource source - new InputSource (r); 
source. setSy stem Id (key); 
RDFCo ns inner consumer - (RDFConsumcr) new 
DatabaseMRConsumer(this) ; 

mSirpac. setRDFSource(source); 

mSiip ac.se tStxcamModc(mUSE_STREAMINO_PARSER); 
mSirpac. register (consumer); 
mSirpac.fetchRDF( ); 

} 



where DatabaseMRConsumer is a callback class invoked 
by SiRPAC that simply invokes the insertTriple( ) 
method of DatabaseMR: 



private class DatabaseMRConsumer implements RDFConsumer { 
private DatabaseMR mNR; 

public DatabaseMRConsumer (DatabaseMR LheMR) 
{ 

mMR - theMR; 

public void start (Data Source ds) { } 

public void end (DataSource ds) { } 

public void assert (DataSource ds, Resource predicate, 
Resource subject, RDFcode object) { 

rnMRuiserlTriplc(predicatc.toString( ), 
subject. tostring( ), object. toString( )); 

} 

}; 



4. Insert each triple into the MR_Jriples_base table using 
a prepared statement of the form: 

INSERT INTO MR_Jriples_base(id, uri_ref, rdf_ 
property, rdf_resource, rdL_object) VALUES(MR_ 
sequence.nextval, ?, ?, ?, ?) 

5. Commit the transaction. 
match( ) 



rdf_resource rdf_property rd£_object 



http^/dlipkin/class 1 http://purl.0rg/dc/clcmcr1ts/l.lAitle HTML 

Fundamentals 

http^/dlipkin/class 1 http7/www.saba.com/RDF/schedule/1.0#startDate 1998-12-07 



The methods of DatabaseMR are implemented as follows: 
importRDF( ) 

The importRDF( ) method imports RDF data. It uses 
W3C's open-source RDF parser, SiRPAC (http:// 
www.w3.org/RDF/Implementations/SiRPAC/) to generate 
triples from an RDF document. 

This algorithm followed by this method is: 

1. See if this document has already been imported. If so, 
delete all triples resulting from the previous import. 

2. Insert the key for this document into M R_sources. 

3. Invoke SiRPAC to parse the document and generate 
triples, using Java code similar to the following: 



The match( ) method takes a MatchDescriptor specifying 
a Match Agent and Delivery Agent and performs a match. It 
uses the following algorithm: 

1. Extract the RDF query and target RDF document from 
the MatchDescriptor. 

2. Parse the query using RQLParscr. 

3. Execute the query by invoking the getResources( ) 
method on the root Operator returned by RQLParser. 
Pass in the target RDF document as an argument, and 
obtain a result Vector of matching resource Strings. 

4. Construct a MatchResultSet of the query results. 

5. Dispatch the query results to the Delivery Agent. 
getProperty( ) 
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The getProperty( ) method returns the value for a specific 
property stored in the MR. It does this by invoking a SQL 
statement of the form: 

SELECT rdL_object FROM MR_triples WHERE rd*_ 
resource^? AND rdf property ? 

Database Schema 

The database schema used has two main advantages: 

1. Simplicity. All RDF data is stored in a single table and 
all SQL is written to read and write to this table. 

2. Support for non-RDF data. It is simple to cast non-RDF 
data into this format so that existing or legacy data can 
be queried by the DatabaseMR using RQL. 

So, for example, for the following example data stored in 
an "invoices" table: 



id 


last updated 


customer 


1 


10- J AN- 99 


Foid 


2 


25-FEB-99 


Cisco 



The view used by the MR can be augmented as followed 



to incorporate this data: 



create view invoice_date_triples as 
select 'lasL_updated* "id£_property", 

('invoiced 1 1 id) "rdf_resource", 
to_char0ast_updatcd, ' YYYY-MM-DD*) M rdL_objecr 
from tesL_in voices; 
create view invoice_customer_triples as 
select 'customer' "rdf^propcrty", 
('invoiced | | id) "rdL_resource'\ 
customer "rd£_object" 
from test_Jnvoices; 
drop view MR_triples; 
create view MR__ triples as 

(select rdf_property, rd£__resource, rd£_objcct from 
invoice_date_tripl es) 
union 

(select rdf_property, rd£_ re source, rdf__object from 
in voice _customer_triples) 
union 

(select rdf_property, rd£_ resource, rdf_object from 
MR^triples_base); 
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This will result in the following additional triples being 
available from the MR: 



rdf_rcsourcc 


rdf_property 


rd£_object 


invoiced 


last_updated 


10-JAN-99 


invoice#l 


customer 


Ford 


invoiced 


last__updated 


25-FEB-99 


invoiced 


customer 


Cisco 
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The disadvantage to this schema is that it is not normal- 
ized and stores a tremendous amount of duplicate data. 
Many values for rdL_resource and rd£_property will be 
duplicated, since the same resource will have a number of 
properties, and property names will come from a well- 
known set. 

RQLParser 
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The Operator interface is defined as follows: 



public interface Operator 

* An operator knows how to return a Vector of matching 
resource values 

* (typically URIs). 

fivpaiam conn JDBC connection to the MR 

* @param targetRDF Thrgct RDF file. 

* @retum Vector of matching resources 

* ©exception SQLException Thrown on a database error 
V 

public Vector getResources (Connection conn, String 
targetRDF) throws SQLException, Parse Exception; 
} /• Operator •/ 



A variety of Operators are provided, each of which is 
responsible for handling different RDF constructs or RQL 
operations. Some of the available Operators are: 

AndOperator — implements the "and'* boolean operator. It 
contains an array of child Operators. It calls getResources( ) 
on each one, then constructs a result Vector of the resource 
that are present in each and every child. 

OrOperator — implements the "or" boolean operator. It 
contains an array of child Operators. It calls getResources( ) 
on each one, then constructs a result Vector of the resource 
that are present in any child. 

SimpleOperator — an abstract class that contains a prop- 
erty string, a value string, and a child Operator. It is the 
superclass for both SingleOperator and ContainerOperator. 

SingleOperator — a SimpleOperator that handles basic 
expressions, ie equals or notEquals. It executes a SQL query 
of the form: 

SELECT DISTINCT rdf_resource FROM (SELECT * 
FROM MR_triples WHERE rdf_property-?) 
WHERE rdf_object [operation]? 

The value for [operation] is provided by the concrete 
subclass. Available subclasses include: 

EqualsOperator 

NotEqualsOperator 

GreaterThanOperator 

LessThanOperator 

LikeOperator 

The value used to match the rdf__object can either be 
provided as hard-coded text in the RQL document, or it can 
be defined as a variable containing a propertyName. In this 
case, a metadata match is performed, using the target RDF 
document as the source for the property value. 

ContainerOperator — a SimpleOperator that operates on 
an RDF container (a Bag, Seq, or Alt). It contains a child 
operator that it executes to return a set of generated 
resources representing the RDF container. It then executes a 
SQL query of the form: 

SELECT rdf_resource FROM MR_triples WHERE 
rd£_property»? AND rdf_object-7 

where each rdf_object is set to one of the child resources. 

Additionally, there is an OperatorRegistry class where 
each Operator is registered with the RQL operation it 
supports. 

RQLParser uses the following algorithm and methods for 
generating the execution plan: 
l.parse(): 

Parse the RQL document using a standard XML parser to 



RQLParser parses an RQL document and builds an execu- 
tion plan for the query. The plan consists of a tree of Java 65 obtain the resulting DOM tree 
classes called "Operators," where each Operator is respon- Navigate to the main condition 

sible for returning a Vector of matching resources. parseCondition( ) on it. 



node and call 



02/02/2004, EAST Version: 1.4.1 



US 6,643,652 B2 



133 



134 



2. parsecondition( ): 

If the condition is a boolean, call parseBoolean( ). 
Otherwise, call parseOperation( ). 

3. parseBoolean( ): 

Obtaining each child node and recusively calling 
parseCondition( ) on each one. 

Create the appropriate Operator for the boolean 
(AndOperator, OrOperator, NotOperator) with the children 
obtained by calling parseCbndition( ). 

4. parseOperation( ): 

Obtain the operation, property, and value nodes. 
Extract the text values of these nodes, and call 
createOperator( ) with these values. 

5. createOperator( ): 

a. Use the OperatorRegistry to obtain the Java class of 
' the* Operator responsible "for this operation. 

b. Use Java reflection to create a new instance of this 
Operator class, passing in the appropriate param- 
eters. 

Agents 

Agents are implemented as clients of the DatabaseMR 
class. 

For example, a simple ImportAgpnt will pass its text RDF 
argument to the importRDF( ) method: 



A simple DeliveryAgent prints the RDF document con- 
taining the matching resources to System. out: 



public class Simp lcDelivcry Agent implements M&tchHandler 

public void deliver (MatchResultSet mrs) throws 
Delivery Exception 



{ 
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Siring xml - mrs.toXMLO; 
System .out.print(xml); 

} 

} /• SimpleDeliveryAgeni */ 



public class SimplcImportAgcnt implements ImpoitAgent 
{ 

private MR mMR - null; 
public SimplcImportAgcnt (MR the MR) 
{ 

mMR - theMR; 

{ 

public void importRDFfString rdf) throws Impo rtException 

Reader r - (Reader) new StringReader(rdf); 
/• this import has a unique key so it can never be 
overridden by 

subsequent imports "7 

String key = "generated" + System.currentTimeMillis( ); 
mMR.importRDF(r, key); 
} /• importRDF */ 
} /* SimplelmportAgent •/ 



A simple MatchAgent will take an RQL document and a 
DeliveryAgent as parameters, and invoke the match( ) 
method: 



public class Simple MatchAgent implements MatchAgent 
{ 

private MR mMR - null; 
private DeliveryAgent mDA - null; 
private MatchDescriptor mMD - null; 
public SimpleMatchAgent (MR theMR, String rql, 
DeliveryAgent theDA) 



{ 



theDA); 
} 



mMR - theMR; 
mDA - theDA; 

mMD - new MatchDcscriptor(rql, 



public void match( ) throws MatchExccption 

^ mMR.match(mMD); 

} /• match V 
} /* SimpleMatchAgent •/ 



Best Mode 

^^VAs indicated earlier in FIG. 3, the architecture of a 
^preferred embodiment of the present invention adopts a 
three-tier model. Referring now to FIG. 17, the various types 
of computer 'hardware and computer software used in a 
preferred embodiment at the present time are depicted in 
20 greater detail. In FIG. 17, a tier 1 user workstation 1701 and 
a tier 1 dedicated user personal computer (PC) 1703 are 
connected electronically to a tier 2 web server 1707 via the 
Internet 1709. FIG. 17 also shows a tier 1 user smart phone 
1705 directly connected to a tier 2 application server 1711, 
25 such as the SABA Business Platform. And the tier 2 appli- 
cations server 1711 may be connected to a tier 3 database 
ma nagement system 1713 . additional external SABA sys- 
tems 1715, external third party systems 1717 and/or third 
party knowledge management systems 1719. 
30 The user workstation 1701 can be a Sun® Ultra5™ 
workstation and the user PC 1703 can be any general 
purpose PC. Note that the list of tier 1 devices presented in 
this preferred embodiment are not conclusive. Other tier 1 
user devices could be WebTV or other Personal Assistant 
35 Devices (PDAs). A Sun E250™ dual processor server can be 
used as a development/test system running the Sun® 
Solaris® operating environment, Oracle® 81. A single pro- 
cessor Sun £250™ server can be used for the SABA 
Business Platform, as a Sun E4500™ dual processor, an 
40 IBM NetFinity 7000™ quad processor with a Microsoft® 
NT™ server and a Hitachi Shared Disk array. The worksta- 
tion 1701 and the PC 1703 can interface to the tier 2 SABA 
Business Platform through the Internet 1709 using a stan- 
dard Internet browser such as Internet Explorer™. The tier 
45 3 database can be located on an Oracle 81® server, a SQL 
server, or Informix. The Sun E250™ dual processor server 
can interface with the external third party systems 1717 via 
third party system specific adapter plugs. The Sun E250™ 
dual processor server also interfaces with external SABA 
50 systems 1715 via SABA exchange. Finally, the Sun E250™ 
dual processor server can also interface with the tier 3 
database management system 1713 located on the Oracle 
81® server. 

Referring again to FIG. 17, the tier 2 applications server 
55 1711 is expanded to illustrate the SABA Business Platform 
(Platform) of the present invention. In FIG. 17, the Platform 
contains an Interface Server 1721, an Information Serv er 
1723. an Interconnect Server 1725, and a business Server 
, (MatchHandlcr) liTf. In a preferred embodiment, all of these Servers 1721, 

60 1723, 1725, and 1727 may physically reside on the same 
hardware platform (such as a UNIX box or a Microsoft™ 
NT™ platform), or each server may reside on a separate 
hardware box, or any combination of servers and hardware 
boxes. Each of the servers has included a JAVA Virtu al 
65 Machine™ and the related runtime suppo rt. " 

TIT a preterred embodiment, the business server 1727 
embodies the containers which incorporate all of the busi- 
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ness logic, common business objects, SABA core objects, 
and a database driven framework for generating notifications 
and for triggering periodic events based on context sensitive 
attachments. The business server 1727 communicates wither 
each of the other servers within the Platform using the XML : 
protocol (1727, 1729, and 1731). The BusmessSejyerJW 
also communicates with the da^abase_niflnasf.rnr.nt system 
1713. In communicating with the interface server 1721, the 
business server 1727 first generates a XML message 1729 
and transmits it to the interface server 1721. The jn terfac e l 
s erver J 72jjhen performs style sheet transfon mtions^orTth e 

the' p arti^lai^Appiicatio ns Prograniming_Interface-(APl) 
lan ^ae-jecKfcjred to communicate_^th-a^particidar user. 
For example' if a particular user is accessing the Platform 
via a workstation 1701 or a PC 1703, the Interface Server 
1721 can convert the XML 1729 into HTML 1735and 
co mmunicate w ith^thejas^Mhrough a~we^^rverT^'Tvia 
the r ]&temetJjZ09 i The Interface server 1 1L\ can also 
convert the XML jnto othe r protocol s such a s WAP/WML 
173^^te^^municate witrTPersonal Da tjTSssis tants (PDAs) 
such as celT phones 1705, PalnTPilots™, or other such 
wireless devices. Since the interface that is generated 
between the Platform and the various user interfaces is 
di ctated by the set of style sheets generated in the Int erface 
Serv er 172 1, the same core business logic can be leveraged 
to communicate across a number of different user interfaces. 

The Interconnect server 1725 uses XML to communicate 
with both the Information server 1723 and the Business 
server 1727 and is responsible for all connectivity external 
to the Platform. Externally, the Interface Server 1721 may 
communicate with third party systems such as SAP™ 
accounting or personnel packages, Oracle™ financial or 
human resources, other SABA Platforms 1715, and gener- 
ally any external system to which a portion of the Intercon- 
nect facilities may be connected. The Interconnect server 
1725 comprises SABA interconnect 1739 which is essen- 
tially a backplane into which cards or interconnect services 
can be plugged. Examples of these cards or interconnect 
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natiyejorniatand transmits t hat data to the Business server 
l'jifwhictT then updates the database management system 
1713. This data connection can be set to be automatic or with 
modifications, — 

In a preferred embodiment, the Interconnect server 1725 
also embodies a workflow and notification scheme. For 
example, if a group of students signed up for a class through 
the Platform and later the class time changes, the Platform 
can detect this change and initiate a workflow to obtain all 
the names of the students from the database management 
system 1713 and send an email to them notifying them of the 
change. Thus, the interconnect server 1725 can provide 
real-time, in-order, reliable updating of data, financial 
transactions, or management of human capital between the 
Platform and third party systems 1717. 

The Interconnect server 1725 can also be used to syn- 
chronize the Platform with other external SABA systems 
1715. For example, the Platform can publish a catalog and 
based on permissions that are set, the catalog can be sub- 
scribed to by some other external SABA systems 1715. 
Whenever changes are made to the catalog, the external 
SABA systems 1715 can monitor that change and obtain an 
update immediately. The Interconnect server 1725 can also 
connect to SABA private learning networks which are 
connected to SABA public learning networks via SABA 
Exchange. For example, a third party such as Ford Auto- 
motive may have a SABA system allowing them to 
exchange catalog or class course information via the inter- 
connect server 1725. 
y^^The Information Server 1723, communicates with the 
Interconnect server 1725 and the Business Server 1727 via 
XML. The Information Server 1723 also communicates 
directly with the database management system 1713 for 
qu ery ^and storage of metadat a 1733. The Information server 
lT &focuses j ^nqueriesa nd distributed queries and kee ping 
trackof informatjo napou Toth er piece s within the Platform. 
TheTnformation Server 1723 can also leverage the Inter- 
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connect server 1725 to conne ct to a third part v_knowledge 
services can be an event monitor 1741, exchange registry, 40 managements ystem 1719H rIat generates information vi a the 



node manager 1747, connectors, accessor 1743, or subscrib 
ers 1745. Each of these cards or interconnect services 
leverage the services provided by the SABA interconnect 
backplane 1739 for communicating between the cards them- 
selves and for providing more sophisticated services to third < 
party systems 1717. 

Apreferred embodiment of the Platform may interconnect 
with a third party system 1717 having, for example, an 
Oracle human resources (HR) database 1749 and an Oracle 
financial database 1751. The third party system 1717 has a 
third party interconnect backplane 1753 with similar cards 
or interconnect services. The third party interconnect back- 
plane 1753 connects to the third party databases 1749 and 
1751 via system specific adapters 1755. These system spe- 
cific adapters 1755 differentiate between different types of 
databases such Oracle, SAP, or PeopleSoft and feed into the 
standardized Platform framework so information can be 
exchanged. An example of information that can be 
exchanged includes HR information. When a new employee 
is added to or terminated from the third party HR system 
database 1749, the monitor 1757 located on the third party 
interconnect backplane 1753 notifies the subscriber 1745 
located on the SABA interconnect backplane 1739 via'XML 
1759. The accessor 1743 on the SABA interconnect back- 
plane 1739 can then access the new employee data via XML. 
The Interconnect server 1725 then performs style sheet 
transformations to convert the XML intQ-.the_£latform , s 



SABA Interconnect bacltplane 1739. For example, a third 
party may have a tHirdTa rt ynnterc onnecUbackplane, 1761 
connect ed to a Kno wledge Management System 1719 which 
monitorsand exchanges data~jvith~'the"Platforrn via XML. 
The Information Server 1723 contains Import, Matc jL and 
Delivery ag ents to reso lve and_g enerate in formation 
r equests fKlatch templates to match metadata; and template - 
bastcTservices that respond to information requests and are 
capable of rendering their results in XML; and Finders — 
so metadata driven, template -based query builders that gener- 
ate optimized SQL queries in the native SQL language of the 
particular database involved. 

Having described the invention in terms of a preferred 
embodiment, it will be recognized by those skilled in the art 
15 that various types of general purpose computer hardware 
may be substituted for the configuration described above to 
achieve an equivalent result. Similarly, it will be appreciated 
that arithmetic logic circuits are configured to perform each 
required means in the claims for performing the various 
( o features of the rules engine and flow management. It will be 
apparent to those skilled in the art that modifications and 
1 variations of the preferred embodiment are possible, such as 
I different computer systems may be used, different commu- 
I nications media such as wireless communications, as well as 
6s different types of software may be used to perform equiva- 
\ lent functions, all of which fall within the true spirit and 
I scope of the invention as measured by the following claims. 
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What is claimed is: 

1. A method for managing data exchange between sys- 
tems connected via a network, comprising: 

creating a plurality of predefined stylesheets, each said 
stylesheet of said plurality of stylesheets describing a 
mapping between a system specific local format and a 
generic interchange format; wherein the generic inter- 
change format is independent of a specific platform or 
system; 

receiving a data object from a first system in a first system 
specific local format; translating said data object from 
a first system specific local format to a generic inter- 
change format object with a first predefined stylesheet 
using a system specific service component which uti- 
lizes a native application programming interface of said 
first system; 

translating said data object from said generic interchange 
- - -'format to a second system specific local -format object 
with a second predefined stylesheet using a system 
specific service component which utilizes a native 
application programming interface of said second sys- 
tem; and 

transferring said second system specific local format 
object to said second system. 

2. The method of claim 1, wherein said step of receiving 
a data object from a first system in a first system specific 
local format comprises: 

receiving a request to export a data object from a first 
system; 

identifying a local data object identifier utilizing a mapper 
component; 

identifying a document type utilizing a mapper compo- 
nent; 

identifying a stylesheet and transformer mechanism using 

said document type; and 
extracting said data object from said first system. 

3. The method of claim 2, further comprising converting 
said local data object identifier to a platform object identifier. 

4. The method of claim 1, wherein said step of translating 
said data object from said generic interchange format to a 
second system specific local format object with said second 
predefined stylesheet using a system specific service com- 
ponent which utilizes a native application programming 
interface of said second system comprises: 

receiving a request to import a data object to a second 
system; 

receiving a data object in a generic interchange format, a 
document type, and a platform object identifier; 

identifying a stylesheet and transformer mechanism using 
said document type; and 

translating said data object from said generic interchange 
format to a second system specific local format object 
with said stylesheet using a system specific service 
component which utilizes a native application pro- 
gramming interface of said second system. 

5. The method of claim 4, further comprising: 
scanning for foreign platform object identifiers; and 
resolving said foreign platform object identifiers to a local 

identifier. 

6. The method of claim 1, further comprising returning a 
local identifier for said data object transferred to said second 
system. 

7. The method of claim 1, further comprising the step: 
monitoring a first system for changes to a data object at 

said first system 

8. The method of claim 1, wherein said step of receiving 
a data object from a first system in a first system specific 
local format comprises extracting said data object from said 
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first system with a system specific service component which 
utilizes a native programming interface of said first system. 

9. The method of claim 1, wherein said step of transfer- 
ring said second system specific local format object may be 
performed using a plurality of communication protocols. 

10. The method of claim 1, wherein said first predefined 
stylesheet is an xsl stylesheet. 

11. The method of claim 1, wherein said data objects are 
in xml format. 

12. The method of claim 1, wherein said step of translat- 
ing said data object from a first system specific local format 
to a generic interchange format object with said first pre- 
defined stylesheet using a system specific service component 
which utilizes a native application programming interface of 
said first system comprises: 

translating said data object into a serialized local XML 
representation; and 
. translating said serialized local XML. representation .to. a „ 
generic interchange format utilizing a predefined 
stylesheet. 

13. The method of claim 1, wherein said step of translat- 
ing said data object from said generic interchange format to 
a second system specific local format object with said 
second predefined stylesheet using a system specific service 
component which utilizes a native application programming 
interface of said second system comprises: 

mapping said data object in generic interchange format to 

one or more objects required to be transferred to said 

second system; and 
translating said generic interchange format data into said 

second system specific local format using a predefined 

stylesheet 

14. An apparatus for managing data exchange between 
systems connected via a network, comprising: 

a network interface; 

memory storing data and programs of instructions; 
a processor coupled to the memory which executes the 
programs of instructions and accesses the stored data, 
wherein the programs of instructions comprise: 
a first translator component for translating a data object 
from a first system specific local format to a generic 
interchange format object, wherein said generic 
interchange format object is both platform and sys- 
tem independent, said first translator component 
comprising: 

a system independent service subcomponent; and 
a system specific service component utilizing a 
native API of said second system to translate said 
data object from a generic interchange format 
object to a second system specific local format 
object using a second predefined stylesheet; and 
a second translator component for translating said 
data object from said generic interchange format 
to a second system specific local format object, 
said second translator component comprising: 
a system independent service subcomponent; and 
a system specific service component utilizing a 
native API of said second system to translate said 
data object from a generic interchange format 
object to a second system specific local format 
object using a second predefined stylesheet; and 
a delivery component for transferring said data 
object between said first and second system. 

15. The apparatus of claim 14, wherein said programs of 
instructions further comprise: 

a monitor component for monitoring changes of a data 
object at a first system, said monitor component com- 
prising: 
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a system independent service subcomponent; and 
a system specific service component utilizing a native 

API of said first system to monitor changes of said 

data object at said first system. 

16. The apparatus of claim 14, wherein said programs of 
instructions further comprise a mapper component for iden- 
tifying a local object identifier and a document type. 

17. The apparatus of claim 14, wherein said first pre- 
defined stylesheet is an xsl stylesheet. 

18. The apparatus of claim 14, wherein said data objects 
are in xml format. 

19. A method for managing data exchange between sys- 
tems connected via a network, comprising: 

creating a plurality of predefined stylesheets, each said 
stylesheet of said plurality of stylesheets describing a 
mapping between a system specific local format and a 
generic interchange format; 

receiving a data object from-a first system in a first system 
specific local format; 

translating said data object from a first system specific 
local format to a generic interchange format object with 
said predefined stylesheets using a system specific 
service component which utilizes a native application 
programming interface of said first system; 

translating said data object from said generic interchange 
format to a second system specific local format object 
with said predefined stylesheets using a system specific 
service component which utilizes a native application 
programming interface of said second system compris- 
ing; 

receiving a request to import a data object to a second 
system; 

receiving a data object in a generic interchange format, 
a document type, and a platform object identifier; 

scanning for foreign platform object identifiers; 

resolving said foreign platform object identifiers to a 
local identifier; 

identifying a stylesheet and transformer using said 
document type; and 

translating said data object from said generic inter- 
change format to a second system specific local 
format object with said stylesheet using a system 
specific service component which utilizes a native 
application programming interface of said second 
system; and 

transferring said second system specific local format 
object to said second system. 

20. The method of claim 19, further comprising returning 
a local identifier for said data object transferred to said 
second system. 

21. The method of claim 19, further comprising the step: 
monitoring a first system for changes to a data object at 

said first system. 

22. The method of claim 19, wherein said step of receiv- 
ing a data object from a first system in a first system specific 
local format comprises extracting said data object from said 
first system with a system specific service component which 
utilizes a native programming interface of said first system. 

23. The method of claim 19, wherein said step of trans- 
ferring said translated data object may be performed using a 
plurality of communication protocols. 

24. The method of claim 19, wherein said stylesheet is an 
xsl stylesheet. 

25. The method of claim 19, wherein said data objects are 
in xml format. 

26. The method of claim 19, wherein said step of trans- 
lating said data object from a first system specific local 
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format to a generic interchange format object with said 
predefined stylesheets using a system specific service com- 
ponent which utilizes a native application programming 
interface of said first system comprises: 
5 translating said data object into a serialized local XML 
representation; and 
translating said serialized local XML representation to a 
generic interchange format utilizing a predefined 
stylesheet 

10 27. The method of claim 19, wherein said step of trans- 
lating said data object from said generic interchange format 
to a second system specific local format object with said 
predefined stylesheets using a system specific service com- 
ponent which utilizes a native application programming 
15 interface of said second system comprises: 

mapping said data object in generic interchange format to 
one or more objects required to be transferred to said- ■ 
second system; and 
20 translating said generic interchange format data into said 
second system specific local format using a predefined 
stylesheet 

28. An apparatus for managing data exchange between 
systems connected via a network, comprising: 

25 a network interface; 

memory storing data and programs of instructions; 
a processor coupled to the memory which executes the 
programs of instructions and accesses the stored data, 
wherein the programs of instructions comprise: 
30 a monitor component for monitoring changes of a data 
object at a first system, 
said monitor component comprising: 

a system independent service subcomponent; and 
a system specific service component utilizing a 
35 native API of said first system to monitor changes 

of said data object at said first system; 
a first translator component for translating a data object 
from a first system specific local format to a generic 
interchange format object, said first translator com- 
40 ponent comprising: 

a system independent service subcomponent; and 
a system specific service component utilizing a 
native API of said first system to translate said 
data object to a generic interchange format object 
45 using a predefined stylesheet; 

a second translator component for translating said data 
object from said generic interchange format to a 
second system specific local format object, said 
second translator component comprising: 
50 a system independent service subcomponent; and 

a system specific service component utilizing a 
native API of said second system to translate said 
data object from a generic interchange format 
object to a second system specific local format 
55 object using a predefined stylesheet; and 

a delivery component for transferring said data object 
between said first and second system. 

29. The apparatus of claim 28, wherein said programs of 
instructions further comprise a mapper component for iden- 

60 tifying a local object identifier and a document type, 

30. The apparatus of claim 28, wherein said predefined 
stylesheet is an xsl stylesheet. 

31. The apparatus of claim 28, wherein said data objects 
are in xml format. 

***** 
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